Re: libtoolize bugs in HEAD

[Ralf Wildenhues]

* Gary V. Vaughan wrote on Thu, Mar 31, 2005 at 05:01:22PM CEST:
> Hallo Ralf!
> 
> Ralf Wildenhues wrote:
> >>Perhaps you have out of date Makefile.in or mismatched bootstrap script?
> > 
> > Obviously not.  Did you use GNU make and bash?

> ] make --version
> GNU Make version 3.79, by Richard Stallman and Roland McGrath.
> Built for powerpc-apple-darwin7.0
> Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99
>         Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.

$  make --version
GNU Make 3.80
Copyright (C) 2002  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

"Interesting."

Digging in CVSROOT/make/NEWS of make..

[ for 3.81 ]
| * Changes made for POSIX compatibility:
|    - Only touch targets (under -t) if they have at least one command.
|    - Setting the SHELL make variable does NOT change the value of the
|      SHELL environment variable given to programs invoked by make.  As
|      an enhancement to POSIX, if you export the make variable SHELL then
|      it will be set in the environment, just as before.

Betcha this will have an impact on some versions of the libtool
testsuite on some systems at some obscure configurations.

Can't find anything relevant between 3.79 and 3.80, however.

[ for 3.79 ]
| * Previously, GNU make quoted variables such as MAKEFLAGS and
|   MAKEOVERRIDES for proper parsing by the shell.  This allowed them to
|   be used within make build scripts.  However, using them there is not
|   proper behavior: they are meant to be passed to subshells via the
|   environment.  Unfortunately the values were not quoted properly to be
|   passed through the environment.  This meant that make didn't properly
|   pass some types of command line values to submakes.
| 
|   With this version we change that behavior: now these variables are
|   quoted properly for passing through the environment, which is the
|   correct way to do it.  If you previously used these variables
|   explicitly within a make rule you may need to re-examine your use for
|   correctness given this change.

I did not know that.  But it's another excellent argument against
libtool using MAKEFLAGS in any way.

 
> ] grep 'SHELL *=' +build/Makefile
> SHELL = /bin/sh

Me too.

> ] head -n 1 bootstrap
> #! /bin/sh

Yes.

> ] /bin/sh --version
> GNU bash, version 2.05b.0(1)-release (powerpc-apple-darwin7.0)
> Copyright (C) 2002 Free Software Foundation, Inc.

$ /bin/sh --version
GNU bash, version 3.00.14(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2004 Free Software Foundation, Inc.

But I don't think it has anything to do with it.

> How odd!  Maybe you are using a newer GNU make?  Or there is something
> in your environment?  Either way, we need to find a way to filter out
> the make output. :-(

Here's the fun:
- output appears on stdout, not stderr  :)))
- it obviously works with --no-print-directory (for GNU make only)
- I have absolutely no idea how to do it portably.

| .SILENT: libtoolize
does not work;

|  ltdldatafiles=`cd libltdl; make -s show-ltdldatafiles`
does not work

| ltdldatafiles=`cd libltdl; make --no-print-directory show-ltdldatafiles`;
works but sucks for obvious reasons.

Putting in `make' literally already sucks for portability.

> > Now don't you think choosing `-I' as the option name is a really really
> > bad idea?  Talk about consistent option naming.  Think stupid user error.
> 
> With handsight, yes, bad name.  Luckily, -I is removed by --patch-11.  Do
> you want me to wait for you to review it some more? Or can I invoke the 72
> hour rule?  I was planning on commiting 11 and 12 tomorrow otherwise...

I replied on respective threads.

Regards,
Ralf