Re: CVS libtool 1.4a fails to install

[Alexandre Oliva]

On Jan 25, 2001, Bob Friesenhahn <address@hidden> wrote:

> If GNU make is not named 'make' then the install target fails for the
> multi-language-branch:
> Making install in libltdl
> gmake[1]: Entering directory
> `/home/bfriesen/src/gnu/libtool-multilang/libltdl'
> Usage : make [ -f makefile ][ -K statefile ]... [ -d ][ -dd ][ -D ][ -DD ]
>              [ -e ][ -i ][ -k ][ -n ][ -p ][ -P ][ -q ][ -r ][ -s ][ -S ][ -t 
> ]
>              [ -V ][ target... ][ macro=value... ]
> make: Fatal error: Unknown option `-w' 

The problem is that, when you intend to use a make program that's not
what running `make' would get, you have to tell configure so by
setting MAKE=/path/to/make.  A configure test introduced by automake
checks whether ${MAKE-make} sets the MAKE variable so that nested
calls of $(MAKE) can be used (needed for sub-directory makes, as in
this case).  Depending on the result of the test, it will introduce a
definition of $(MAKE) itself, that will override the definition GNU
make would provide, in case you run it instead of ${MAKE-make}.

Please let me know if setting MAKE=gmake in the environment before
running `configure' fixes the problem for you.  It would probably be
safe if GNU make didn't add `-w' to $(MAKEFLAGS) if MAKE is explicitly
overridden to a non-GNU make program.  Similarly, automake could set
MAKEFLAGS to empty whenever it detects that ${MAKE-make} doesn't set
${MAKE}.  This would probably get us rid of the problem without losing
any functionality, since it's unlikely that a MAKE that doesn't set
MAKE sets MAKEFLAGS.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  address@hidden, redhat.com}
CS PhD student at IC-Unicamp        address@hidden, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me