Re: [Gnucap-devel] Autotools build system

[al davis]

On Sunday 07 June 2009, Kevin Bowling wrote:
> I would like to fix up the autotools build system and address
> any short comings Gnucap is having.  You've said before that
> it is broken or not optimal.  Can you list any specific
> cases?  I will post patches to the list when this work is
> complete.

How do I start on this one?

I have never seen the autotools build system really work well, 
anywhere, but it seems the new alternative build systems throw 
out the good parts (make) and rewrite the bad parts in another 
language, so they are even worse.

In spite of that, I acknowledge the need for it, and feel that 
for now there is no alternative, as I look with trepidation at 
updating the gnucap autoconf system as is needed for plugins.

I have kept the old build system for two reasons .. One is as a 
backup for when autotools don't work.  The other is that the old 
system is much nicer for development.  It was never intended as 
a "product" like autotools, but I think it has potential if 
somebody wants to finish the job.

Basically, the old build system uses a 3-part Makefile.  You cat 
the 3 parts.  Make1 is program specific, like the autotools 
Makefile.am.  Make2 customizes to the environment.  It is the 
piece that would be generated by a configure script, or can be 
manually edited.  Make3 is boiler plate.  It contains things 
like target definitions that never change.  For it to become a 
viable replacement for autotools, it would need more targets in 
Make3 and more tests in the configure script.  Most of this 
could be copied from autotools!

What is needed now is update of both versions to properly handle 
plugins.  Also needed is a refactoring of code separating core, 
includes, main, and plugins.

Henrik suggested making most of the core a library, with a very 
minimal main program.  I agree that we need to do at least what 
Henrik suggested, most likely more.  Since we are rearranging 
anyway, it is probably appropriate to do it now.

I consider choosing which plugins to static link to be something 
a regular user building the program should be able to do.  This 
is not supported by autotools as far as I know.

The installation needs to produce something like this:
- a main executable, installed where executables normally go.
- includes, installed where includes normally go
- plugins available system-wide, intalled like libraries.
- each plugin must be considered separately
- a simple way to build user plugins with a simple Makefile
- a place for things like spice-wrapper.cc and the plugin Make2.

Is this enough to get you started?

al.