Re: Some weird bug with non gnu-make

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Marc" == Marc Espie <espie@schutzenberger.liafa.jussieu.fr> writes:

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

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

This isn't specific enough for me to do anything about.  I'm sorry
that you are angry.  But venting is unlikely to induce anybody to
address your complaints, even if they were detailed enough to address.
Mostly it makes me want to flame you.  Saying that these tools "never
ever work" and that they are "completely broken" is unwarranted,
annoying hyperbole.

As far as only working on GNU/Linux, that is simply false, at least
for automake.  Automake-generated Makefiles, when Makefile.am is
correctly written, are extremely portable.  For instance, they work
around bugs in vendor makes and shells.

Yes, if you enable automatic dependency tracking with automake 1.4,
then you get a nonportable Makefile.  This is documented, and
endlessly discussed on the automake list (perhaps the most frequent
complaint -- we probably got the default wrong here).  This problem is
eliminated in the cvs automake.  If this is what you're referring to
then RTFM.

Is automake perfect?  No, of course not.  Is it even useful?  Opinions
vary, with good reasons on both side.  Automake comes from a certain
background, and as it is moved into new arenas we find that old
decisions no longer fit.  So, we work to change them.  Sometimes we
work slowly, since it is all volunteer.  I know it is frustrating for
you (and others) when automake (or autoconf, or libtool) doesn't work
as well as you might like.  It is also frustrating for me to see the
tools endlessly criticized in unrealistically terms, particularly when
the criticism is unfocussed and not helpful to further development,
like yours above.

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

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

Write your own .c.lo rule:

    .c.lo:
	    $(LTCOMPILE) --tag CC  [ ... ]

That ought to work as a workaround.

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

I don't know.  It does in cvs.

Tom