Re: Autotools build system

Hi Al (and all),

> The "old" build system is really just plain old "make", with a
> tiny configure script to provide an interface like autotools,
> for those who want it.  Where autotools generates a monstrosity
> of a Makefile, the "old" system cats three pieces, each one is
> simple.
>
> Every time I try to do anything with autotools, I give up in
> frustration.

Sometimes, it just takes a little demonstration to show the way.
My early frustrations were quickly forgotten, after I found good examples, 
(read the docs), and became comfortable with writing from scratch.  And 
besides, you can write standard Makefile rules/dependices in automake 
files.

The "thousands" of lines of generated Makefiles include shell scripts for 
structured distribution generation, installation, uninstallation, and 
checking (lots and lots of checking), that many hand-written boilerplate 
Makefiles lack or fall short.  Building is just a piece of software 
development.

> Considering that in my experience, auto* rarely works correctly
> on mainstream systems, I shudder to think what it is like on a
> non-mainstream system.

Perhaps we should look into why you've observed so.  I've had much better 
experience porting to older and less common platforms.  For every build 
system out there, there exist poor examples (I've seen some hideous 
Makefiles in my days -- some people have been so scarred, that they prefer 
to write perl-scripts and straight-line shell scripts over Makefiles.)

> Before auto*, I could always figure out what to hack.
> I don't have confidence in it.  Aside from the fact that I haven't 
> figured out how to gracefully turn debugging features on and off, how to 
> simultaneously do multiple builds with different options, and lots of 
> other things that are trivial with plain old "make", it seems that most 
> of the time I try to build some package that uses autotools, it doesn't 
> work and the messages are not at all useful at figuring out what is 
> needed.  Just compiling and letting it fail gives more useful 
> information.

Don't panic.  Since we are proposing the idea, it will be our 
responsibility to show you how the 'old-way' maps to the 'new-way', and 
convince you to give it another shot.

> I am still bewildered about the relation between autotools and
> "libtool".  It seems to me that if autotools is doing its job,
> libtool isn't necessary.

Libtool's power come from the way it handles dynamically linked libraries, 
including both shared libraries, and plug-ins.  Without it, automake is 
really only capable of working with static (.a) libraries.  For instance, 
libtool helps link your executable so that it can run pre-installed with 
shared libraries (for pre-install testing), and then post-installed. 
IMO, the little nuances between shared libraries on different platforms 
and compilers and linkers are the biggest obstable to portability. 
libtool handles all of it transparently.

> There is a new challenge now with plugins, that I think is
> satisfied by the "old" system and not by the new one ..  With
> the "old" system, a plugin only needs the first part of the
> Makefile, and you can compile with just "make".
>
> So, if the choice is one or the other, let's COMPLETE the old
> one.  I think that is easier than FIXING autoconf.  Also, I
> think the world would appreciate it.  Done right, it could be as
> much of an improvement over autoconf as Git is over RCS.

I'm rather busy until the weekend.  Over the weekend I should have some 
time to work with you, Kevin and other interested developers on drafting 
the autotool files, hopfully getting around to plug-ins.

Remember, we are trying to make your life easier!

Best,

Fang


David Fang
http://www.csl.cornell.edu/~fang/
http://www.achronix.com/