Re: [Gnucap-devel] Autotools build system

[al davis]

On Sunday 14 June 2009, Kevin Bowling wrote:
> Indeed, autotools are not a magic bullet.  However,
> maintaining our own build system seems unnecessarily time
> consuming. 

It is often presented as a magic bullet.

The "old" build system takes nearly zero time to maintain.  I 
would estimate that the total time invested in Gnucap's use of 
autotools is at least a thousand times the total time invested 
in the old system, which dates back to when "shar" files were 
the usual distribution mechanism, and hasn't really been updated 
since.  

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.

I think I have a pretty good grasp on what it will take to make 
the "old" build system do what it needs to do, and where to 
steal the code.  (Autotools, of course.)

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

But, some people like it, so it is provided for them.

> It also will make it hard for users to build
> Gnucap on platforms we don't have access to.  A lot of this
> comes free with auto*.

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.

Before auto*, I could always figure out what to hack.

On Sunday 14 June 2009, Kevin Bowling wrote:
> Having two build systems is both confusing to
> users/developers and cumbersome.  My vote is to take the time
> now and fix one or the other, and only carry it in the
> default package.  I have confidence that autotools can be
> made to work since many complex projects make use of it.

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.

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.

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.