libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 278-gary-libtoolize-without-automake-or-AC_CONFIG_MACRO_DIR.diff


From: Ralf Wildenhues
Subject: Re: 278-gary-libtoolize-without-automake-or-AC_CONFIG_MACRO_DIR.diff
Date: Fri, 23 Sep 2005 15:59:47 +0200
User-agent: Mutt/1.4.1i

Hi Gary,

* Gary V. Vaughan wrote on Fri, Sep 23, 2005 at 03:49:34PM CEST:
> Ralf Wildenhues wrote:
> >* Gary V. Vaughan wrote on Fri, Sep 23, 2005 at 02:17:43PM CEST:
> >>For users that have an old style configure.in without AC_CONFIG_MACRO_DIR,
> >>and who don't use Automake (hence no `ACLOCAL_AMFLAGS = -I m4'), 
> >>libtoolize currently refuses to copy any of libtool's Autoconf
> >>macros.  This changeset reverts to the 1.5.x behaviour of dropping
> >>them in the current directory in that case.
> >
> > .. no, it doesnt, AFAICS:
> >
> >$ libtoolize
> >| You should add the contents of `/usr/share/aclocal/libtool.m4' to
> >| `aclocal.m4'.
> >
> >I don't think we should change this.  People should adapt to the new
> >way, and since they need to make modifications anyway, they might as
> >well not be hit by an update incompatibility.
> 
> That's 1.5x libtoolize you're running, no?

Yes.

> >Did I miss something?
> 
> No.  Here is the scenario (I'm polishing a test that does this atm):
> 
> Say I want to start to update the configury on my old non-automake
> project, starting with libtool -- considering our excellent reputation
> for backwards compatibility ;-)  Let's simulate that:
> 
> $ cat <<EOF >>configure.in
> AC_INIT(main.c)
> AC_PROG_LIBTOOL
> AC_OUTPUT(Makefile)
> EOF
> $ touch Makefile.in main.c
> 
> Now, having installed libtool-2.0, our hypothetical upgrader does this:
> 
*snip*
> $ autoconf
> configure.in:2: error: possibly undefined macro: AC_PROG_LIBTOOL
>       If this token and others are legitimate, please use m4_pattern_allow.
>       See the Autoconf documentation.

Not true.  She runs aclocal and thus gets the libtool macros into
aclocal.m4.  This is what she would've had to do with 1.5.x as well.
So there is no such problem the way you described.

> $ ls
> total 88
>  Makefile.in      config.guess   configure      install-sh   main.c
>  autom4te.cache   config.sub     configure.in   ltmain.sh
> $ libtoolize --install --force

libtoolize 1.5.x does not know `--install'.

> libtoolize: linking file `./config.guess'
> libtoolize: linking file `./config.sub'
> libtoolize: linking file `./install-sh'
> libtoolize: linking file `./ltmain.sh'
> $ autoconf --force
> configure.in:2: error: possibly undefined macro: AC_PROG_LIBTOOL
>       If this token and others are legitimate, please use m4_pattern_allow.
>       See the Autoconf documentation.

See above.

> Actually, I didn't know libtool.m4 would still work by itself, which
> is why I was going to drop all the macros in `.' and get the user to
> add them to aclocal.m4.  You're right that the old message is cleaner.
> I'll fixup the patch and repost presently.

Yes, and please _don't_ change the libtoolize behavior.

By the way,
$ libtoolize-1.5
links config.guess, config.sub, install-sh, whereas with
$ libtoolize-2.1
you also need --install.  Another incompatibity?

So: if you want to copy libtool.m4, educate users to use
AC_CONFIG_MACRO_DIR, and if only with [.] as argument.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]