Re: [Gnucap-devel] Autotools build system

[David Fang]

Hi,
	I realize that I misinterpreted what you meant by 'static' before; 
--enable-static has nothing to do with the organization of your libraries, 
but rather how binaries are linked.  You just want the user to elect which 
features/modules are pre-loaded on starting your main executable. 
(Correct me if I'm wrong.)  You intend to have some set of default 
built-ins loaded, and the rest manually loadable.

> > > 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:
--->8 snip 8<---
> > 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.

I think he meant the list of all plugins that come with the baseline 
package.  It's up to you which subset of those plugins from the base 
package you want to make optional.

> 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.

Why not make every plug-in loadable via the following:
* command-line invocation when executable is run (e.g. -l featureXYZ)
* in-program command-line loading (e.g. "% load featureXYZ")
* configuration text file, editable by the user, like a .gnucaprc

This way you don't need to worry about adding configure-time options 
(decide later!).  The build system can just build all plugins with the 
base package (unless explicitly disabled, or missing prereq is detected).
This gives the most flexibility to the user without having to make 
decisions up-front.  This is how many extension languages work (perl, 
python, guile/scheme, tcl).
When a new plug-in comes along and is installed, the user just amends her 
configuration file to load the new module.

This method is orthogonal to choice of build system, but using libtool to 
manage building and installing of plug-ins is still what I'd recommend for 
best portability (and ease of maintainence).

Fang

David Fang
http://www.csl.cornell.edu/~fang/
http://www.achronix.com/