Re: Some weird bug with non gnu-make

[Marc Espie <espie at schutzenberger dot liafa dot jussieu dot fr>]

Nope, this thing is completely broken.  Since this list is somewhat
politically correct, I won't use the words that come to my mind, suffice
it to say I hate those automated tools that never ever work, are always
inflexible when I need them to flex, and never ever produce files that 
work on anything but GNU/Linux.


Why can't those magic tools `just work' ?

So, that patch doesn't fix the magic line that needs fixing.
Namely, the problem is compiling signbit.c, and THAT one is done through
the default target...

In the end, this comes from the libtool.am fragment of automake, which
looks like this:

NOTDEPEND.c.lo:
## Note that we explicitly set the libtool mode.  This avoids any lossage
## if the program doesn't have a name that libtool expects.
NOTDEPEND       $(LIBTOOL) --mode=compile $(COMPILE) -c $<


and I would tend to assume  that changing this to insert --tag CC
is a bad idea.


Now for the $10000 question: why doesn't
.c.lo:
    $(LIBTOOL) --mode=compile $(COMPILE) -c $<

use LTCOMPILE ???

Guess I will need to go back to hunt and find out that bloody extra space
that libtool is dumb enough to care about...