[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: Sun, 21 Jun 2009 00:36:37 -0400 (EDT)

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

Hi Al,
Would the user's experience feel any different if modules were always built separately, but always loaded on startup? (as opposed to being linked in statically as say, a dependent library.) If the common case is to have a core set of plug-ins loaded, then you could provide a command-line option to skip loading them, in the rare event that they are not wanted.

I am thinking of several situations:
- where plugins don't work

If you want a plug-in archtecture, you might have to leave out systems that absolutely cannot support them. libtool is capable of emulating plug-ins with static libraries on some older systems, i.e. load static libraries like plug-ins. (See chapter 9 of the libtool manual.)

- a "demo" version that is a simple executable (usually for MS-
Windows) and nothing else

You can always add such an executable to
if WIN32
bin_PROGRAMS += gnucap-win32-demo

and link it statically.

Why not make every plug-in loadable via the following:
* command-line invocation when executable is run (e.g. -l
* in-program command-line loading (e.g. "% load
* 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.

The patch I submitted introduced a 'dlopen' command that you can call without the module's file extension, thanks to lt_dlopenext(). To load-dir, you just need to traverse a DIR/dirent <sys/dir.h>/<sys/dirent.h>. Not sure what the equivalent is for Windows.
I've been testing on an old Mac.  :)

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.

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?

The patch I sent is an example of this. The models with the base package are bundled into an all-or-none plug-in. I didn't bother to provide a startup script that pre-loads the plug-ins.

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

Let us know what you think!


David Fang

reply via email to

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