Re: Get rid of libtool? [was Re: Makefile problems]

[Nathanael Nerode]

On Thu, Jul 04, 2002 at 01:01:15PM -0600, Tom Tromey wrote:
> >>>>> "Nathanael" == Nathanael Nerode <address@hidden> writes:
> 
> [ moved to the automake list ]
> 
> Nathanael> On the other hand, the better I understand Automake, the
> Nathanael> more I HATE it.
> 
> Over 1 million now served.
I hate McDonald's too. :-)

> I found your message pretty irritating, since it is just a bunch of
> assertions without any real supporting evidence.  Please help us make
> tools better; random "automake sucks" flamage is pretty useless.
Sorry.

> Nathanael> It makes it waaay easier to generate nasty, stupid
> Nathanael> dependency problems.
> 
> Can you explain this comment?
Yes.  <rant>

Automake is quite good at generating dependencies for things which
behave 'normally': C files compiled to O files with the same name, & so
on.  In fact it appears to do so via ordinary suffix rules.

Automake does little or nothing to help generate dependencies for
unusual cases; it can't, no automated tool can.  What it does do is to
demand extra work for the maintainer in order to tell Automake that
theses *are* unusual cases.  This isn't positive for dependency
handling. 

> Nathanael> It does a poor job of getting dependencies right
> 
> And this one?  I think automake does a very good job here.  We've
> spent a lot of time on dependency tracking.
I'm not talking about automatic dependency generation for C headers;
that's really a separate issue in many ways.  I'm talking about the same
thing I'm talking about above.

I guess what I'm saying is that I like a tool which makes things simple,
but not TOO simple.  I think automake oversimplifies, to the point where
it's making assumptions about the nature of files and how they're
used, which are only true some of the time.  Although it allows you to
override its assumptions, doing so is generally harder than writing a
raw Makefile.  (At least for someone who understands Horn clauses!
Don't they teach PROLOG in CS departments any more?)

I have a philosophical bone to grind here, and I admit it.  I think
developers ought to write out the dependencies in their build.  It's
great to say "let's do it automatically", but it *can't* be done
automatically, because each project is structured differently.  It's
wise to allow developers not to write dependencies *twice* (hence
automatic C header dependency generation, since the dependencies are
written in the C and H files already; also the information in 'clean'
rules is in many ways redundant with specified dependencies). It's wise
to allow developers to specify a whole bunch of similar dependencies at
once (suffix & pattern rules, autogenerated rules).  I don't think it's
wise to tell developers that a program will 'take care' of their
dependencies, and unfortunately that's the message being sent out by
automake.

Makefile dependencies are easy to write if you have the first clue about
how 'make' works, and you know what your dependencies are.  The message
sent by automake, sadly, is "Make is a bad tool.  Make is hard to use."

[ Makefile *rules* are another matter; 'make' was designed with the idea
that all rules would be simple one-liners, but it can be hard to
actually write rules in that form.  Libtool *helps* write rules in that
form, which is why I like it. :-)  One of the primary (good) uses of
Make macros was to allow rules to be written in that form, but that use
is mostly obseleted by autoconf subsitutions now, really. I have a lot
of respect for the rather slick definitions of 'COMPILE' and 'LINK' used
by automake, although the nested use of macros is worrisome from a speed
point of view.  It's not as unhealthy as the use of macros in
dependencies, though. ]

> Nathanael> I don't see an easy way of fixing most of the problems even
> Nathanael> with a complete rewrite (although some of the functionality
> Nathanael> could be better implemented with a few command-line
> Nathanael> enhancements to 'make'... but that's a complicated other
> Nathanael> story).
> 
> The whole point is not to require changes to make.  If we could do
> that, then we could eliminate a lot of automake.  Or just use a better
> tool to start with.
There's actually a subtle concept I had here, which is why I said
it was another story.  The command line options I want would only be
used by maintainers, or for diagnostics, and would not need to be
present in the 'make' used by people building and installing.  I want 
the ability to see what the dependency tree looks like once all the
macros have been expanded, *without* looking at all the rules. But as I
said, it's another story.

Make isn't a bad tool, it's an abused tool.  (It does have a
typo-diagnosis problem, true.)  There really isn't a better way to
express dependencies than Make's way, although better ways of getting
alternative information out of the dependency tree would admittedly be
lovely.

> Nathanael> An example of this is the way *Automake* uses libtool.  Not
> Nathanael> libtool itself, but the way automake uses it.
> 
> Please explain.
Yes. Automake thoughtfully specifies the same libtool command and
simplistic dependencies for all objects being built.  This is *sort
of* nice. In the 10-20% of cases where you want weird behavior, you have
to write it by hand.  Which *would* be fine, except that automake
documentation tells you that you don't need to write it by hand, libtool
documentation is less than would be desirable on using libtool without
automake (the information's actually mostly there, in fact, but its
use is actively discouraged), and automake-generated Makefiles are
often nearly undecipherable.

Automake allows for great customixation at the linking level (all done
with Makefile macros) which is in contrast to its treatment of
what it considers 'intermediate' files.

</rant>
--Nathanael