Re: Autotools build system

> 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 Makefile.am:
if WIN32
bin_PROGRAMS += gnucap-win32-demo
endif
...

and link it statically.

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

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!


Fang


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