[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] Autotools build system

From: David Fang
Subject: Re: [Gnucap-devel] Autotools build system
Date: Sat, 20 Jun 2009 14:55:21 -0400 (EDT)

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

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


David Fang

reply via email to

[Prev in Thread] Current Thread [Next in Thread]