Re: [Gnucap-devel] Autotools build system

[Kevin Bowling]

On 6/19/2009 6:19 PM, al davis wrote:
> > > 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.
> > >        
>
> With a plain Makefile, I would just edit the Makefile to add the
> files I want to include.
>
> On Sunday 14 June 2009, Kevin Bowling wrote:
>    
> > 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.
> >      
>
> You can't list the plugins in the main Makefile.  You can't know
> the entire list of possible plugins.
>
> This rule applies to the program source too.  The core has no
> listing of what plugins might be used.
>
> The only way I can think of to let the user specify what plugins
> to static link is to let the user explicitly list  them,
> somewhere, or to include a file containing such a list.
>    
Hi Al,

I deferred to Diego Pettenò of the Gentoo Linux project (among many 
others).  He is an expert on packaging and building GNU software.  He is 
heavily involved with the Xine project.  If you know about multimedia, 
Codecs are basically plugins that the build file might not know about at 
runtime, just as you said we need in Gnucap.

Introduction aside, he is publishing a fantastic autotools guide:  
http://www.flameeyes.eu/autotools-mythbuster/index.html.  When I 
discussed the requirements of Gnucap with him, he did a blog post about 
plugins vs. builtins for everyone to see:  
http://blog.flameeyes.eu/2009/06/18/plugins-and-builtins-what-s-the-best.

I don't think your buildsystem is bad by any means, so I asked Diego for 
advice on choosing how to proceed.  He stated essentially "its not about 
the developers, but rather the distributions"  Supporting hundreds of 
custom build systems must truly be a nightmare.  Like it or not, 
autotools is the de facto system for GNU software.

The average user should be able to simply install Gnucap from their 
distro of choice (Fedora and Gentoo already do this -- I checked Gentoo 
and they use the autotools build.  I'd bet the SRPMs of Fedora are the 
same).  We make that easier by sticking to the standards.

Again, I don't think there is anything we are doing that can't be 
handled by autotools.  In fact, it should keep things seemless when 
building across platforms like Mac OS X that do libraries completely 
differently.  I'm interested in improving Gnucap, not handling bizarre 
build quirks in operating systems I don't care about.

Regards,
Kevin Bowling