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

[Nathanael Nerode <neroden at doctormoo dot dyndns dot org>]

I'd rather not get rid of libtool; I'd rather improve it until it works
right.  It's actually not a bad tool, but it has the wrong command-line
semantics for Makefile purposes.  The *purpose* of libtool is to
abstract away the differences in shared library generation.
Accordingly, you ought to be able to write

x.lo: x.c x.h y.h ...
	libtool $(CC) -c x.c
x.o: x.c x.h y.h ...
	libtool -static $(CC) -c x.c

Unfortunately, libtool insists on doing both the static and shared
generation at once. This is a problem when writing dependencies, but it's 
one which small changes to libtool could fix.

Then, for linking:

libhello.la: foo.lo hello.lo
	libtool $(LINK) -o libhello.la foo.lo hello.lo
libhello.a: foo.o hello.o
	libtool $(LINK) -o libhello.a foo.o hello.o

Again, libtool insists on doing both at once, which makes writing
correct, non-redundant dependencies very hard.  This is still a problem
which could be fixed really easily in libtool.

Linking against uninstalled libraries:

program-static: main.o libhello.a
	libtool $(LINK) -o program-static main.o libhello.a

program-shared: main.lo libhello.la
	libtool $(LINK) -o program-shared main.lo libhello.la

And again, the problem is that libtool insists on doing both at once.

Pretty much the same damn thing happens with install.

However, if this one repeated problem was fixed, encoding
libtool-related dependencies into Makefiles would be quite
straightforward and would work the Way It Is Supposed To.

It wouldn't even need to break libtool backward-compatibility, provided
it was implemented as libtool options --only-shared and --only-static.

Note that with separate rules for shared and static libtool running,
and potentially separate arguments to libtool on a per-file basis, it
becomes easy to add specific shared-library options which are wanted by
a specific library, or indeed to put an entirely custom non-libtool rule
for particularly hairy cases.

If one subdirectory is always built with a particular unusual set of
requirements, it can even have its own libtool.  And it will all work
out all right.

---

On the other hand, the better I understand Automake, the more I HATE it.
It makes it waaay easier to generate nasty, stupid dependency problems.
It does a poor job of getting dependencies right, and creates makefiles
which can't be read and are therefore hard to debug.  I don't see an
easy way of fixing most of the problems even with a complete rewrite
(although some of the functionality could be better implemented with a
few command-line enhancements to 'make'... but that's a complicated
other story).  

Most of the really irritating repetitive stuff which
automake abstracts away can be better done using pattern rules, or
'autogen' if you want to work in terrible makes.  Most of the other
stuff it abstracts away can only *be* abstracted away correctly 80% of
the time, which leads to endless problems.

An example of this is the way *Automake* uses libtool.  Not libtool
itself, but the way automake uses it.

Automake also makes massive use of Makefile macros, which are a known
and proven way to make Makefiles lots slower.

I would support any movement to dump automake; it seems to help people
create bad Makefiles.

--Nathanael