Re: [Gnucap-devel] Autotools build system

[al davis]

On Saturday 20 June 2009, David Fang wrote:
> 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.

Close  ...

I want the person building the executable to be able to select 
which modules are compiled-in.  Others are manually loadable.

I am thinking of several situations:
- where plugins don't work
- a "demo" version that is a simple executable (usually for MS-
Windows) and nothing else

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

But I didn't.

> 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

It is that way now.  I don't plan to change it.

Actually, I do plan one change ...  As it is, the "load" command 
loads one module.  You name a file, complete with extension, 
which is ".so" on Linux, ".dll" on MS-windows.  I want to add a 
feature that lets you load a directory, which means all modules 
in that directory, or if there is a Makefile to run make then 
load all modules in that directory.

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

So, you are suggesting (and answering my question from another 
post) that dynamic loading is the only option, and that none are 
compiled into the executable by default?

Taken to the extreme, it means that the main executable will do 
NOTHING by itself, until some plugins are loaded.  Should this 
be the default?

This is a valid choice.  I would like some comments about 
whether or not it is the best choice.

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

I have no problem with libtool.