[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] Autotools build system

From: David Fang
Subject: Re: [Gnucap-devel] Autotools build system
Date: Thu, 18 Jun 2009 04:01:52 -0400 (EDT)

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

Every time I try to do anything with autotools, I give up in

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!



David Fang

reply via email to

[Prev in Thread] Current Thread [Next in Thread]