Re: FYI: use `&&' to separate commands in the untar process [libtool--release--2.0--patch-56]

[Ralf Wildenhues]

Hi Gary,

* Gary V. Vaughan wrote on Fri, Mar 11, 2005 at 02:05:09PM CET:
> Ralf Wildenhues wrote:
> > | ( cd ../../libltdl && /bin/sh 
> > "/mount/endor/wildenhu/download/software/libtool/write/libtool/config"/missing
> >  --run tar chf - COPYING.LIB README  Makefile.am Makefile.in  configure.ac 
> > configure  ltdl.c ltdl.h  lt_error.c libltdl/lt_error.h  
> > libltdl/lt__private.h  libltdl/lt__strl.h  libltdl/lt_system.h  lt__alloc.c 
> > libltdl/lt__alloc.h  libltdl/lt__glibc.h  libltdl/lt__dirent.h  slist.c 
> > libltdl/slist.h  lt_dlloader.c libltdl/lt_dlloader.h loaders/preopen.c  
> > lt__dirent.c libltdl/lt__dirent.h  lt__strl.c libltdl/lt__strl.h  argz_.h 
> > argz.c; )  | ( umask 0 && cd 
> > /mount/endor/wildenhu/download/software/libtool/install/libtool-2.1/share/libtool-2.1a/libltdl
> >  && /bin/sh 
> > "/mount/endor/wildenhu/download/software/libtool/write/libtool/config"/missing
> >  --run tar xf -; )
> > | tar: configure: Cannot stat: No such file or directory
> > | tar: Error exit delayed from previous errors
*snip*
> > 
> > for the very simple reason that there is no `configure' in libltdl
> > because we eliminated configuring in there some time ago.  So: Is
> > there an actual problem w.r.t. `&&' vs `;'?  Did `make install'
> > work for you before?  Why?
> 
> Ah yes... D'oh!  I *do* have a configure in libltdl atm...

Now, does that mean there was never a problem w.r.t. `&&' vs. `;'?
Sorry if I'm dense here.

> > OK to apply patch below?
> 
> That was some of my next patch leaking out :-(  Sorry about that.
> 
> No need to apply your patch.  We need to generate a configure script
> plus all the other config droppings to be installed to $pkgdatadir/libltdl,
> so that `libtoolize --ltdl' is useful to developers that don't use auto*.

I don't believe they can get by without auto*.  But I'd be happy to be
proven wrong.  (I'd demand a test for this, though, so that it does not
break again.)

One simple reason I don't think this can work: a package-toplevel
Makefile.in looks different from a non package-toplevel Makefile.in.
branch-1-5 creates a package-toplevel one in libltdl/, but newer Libtool
does not.  We just can't use the same for both.

> I experimented with:
> 
>    i) bootstrapping with libtoolize (what we do currently)
>       - but that requires auto* on the developers PATH
>    ii) bootstrapping at make install time
>       - the installer needs auto* on their PATH
>    iii) bootstrapping at configure time
>       - the installer still needs auto* on their PATH
>    iv) copying the correct files from elsewhere in the source
>        tree at install time
>       - keeping the timestamps in synch to prevent rerunning auto* when
>         the libtoolize --ltdl directory user first runs make is too brittle
> 
> The only solution is to bootstrap libltdl from the bootstrap script.  Even
> though libtool doesn't subconfigure, users of libtoolize --ltdl might want
> to.

While I don't understand what you meant with the different items above,
I'd be happy to see a patch that solves this.  :)

Cheers,
Ralf