Re: Autotools build system

(Sending again, mailing list didn't pick this up?)

On 6/8/2009 7:44 PM, al davis wrote:
> 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.
>>      
>
> 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.
>    
> 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.
>    
Indeed, autotools are not a magic bullet.  However, maintaining our own 
build system seems unnecessarily time consuming.  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*.

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.
> 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.
>    
These two items need to be elaborated on.  Do you have any idea what 
parts you'd like to handle, and what others might do so we are not 
stepping on toes?  Perhaps we can do task assignments with a system like 
I am using to run the + project, or something else if you prefer (Gnucap 
wiki?).
> 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.
>    
I believe we can set conditionals.  For example, in configure.in:

AM_CONDITIONAL(STATICPSS, test "$enable_staticpss" = yes)

When the user specifies ./configure --enable-staticpss, this variable 
will be passed to the Makefile.

In the plugin directory's Makefile.am (gnucap/plugins/pss):

if STATICPSS
lib_LIBRARIES = libpss.a
libpss_a_SOURCES = pss.cc
endif

In the main Makefile.am:
if STATICPSS
gnucap_LDADD += $(top_builddir)/plugins/pss/libpss.a
gnucap_CPPFLAGS += -I $(top_builddir)/plugins/pss/pss.h
endif

This is a bit simplified, but I think a solution using something like 
this would be elegant.  We would need to set defaults for which modules 
to build, but could also parse --disable-<x> statements to remove core 
static modules.
> 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.
>    
Seems easy enough by making use of PREFIX and such during make install 
and directing files where they need to go.
> - each plugin must be considered separately
>    
How will dynamic plugins compare with static?  I suppose the conditional 
system could be used here as well.  They would be dumped in 
{PREFIX}/{LIBDIR}/gnucap.
> - a simple way to build user plugins with a simple Makefile
> - a place for things like spice-wrapper.cc and the plugin Make2.
>    
Can you elaborate details on these requirements.
> Is this enough to get you started?
>    
Yes.  It looks like we will have to discuss my questions and comments 
before proceeding.

Regards,
Kevin