Re: Autotools build system

On 6/20/2009 8:51 PM, al davis wrote:
> 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.

What do you mean by "compiled in"?  To me that means statically compiled 
and then linked into the 'gnucap' binary so the user doesn't need to 
worry about shared objects.  Otherwise, just continue to let the user 
edit a text file of default load commands for shared objects.

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

Loading an entire plugin directory makes a lot of sense.  
Libtool(libltdl) should do exactly what we need (hide the complexity of 
different dynamic loading mechanisms and library types -- crossplatform).

But dynamically running a Makefile?  For what purpose?  Let us assume 
the average user's machine, especially Windows, doesn't have gmake let 
alone a C compiler.

>> 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.
I'm not against this, as it would make things easier.  If the libtool 
implementation is successful, most people wont care.  David?

I guess a favorable outcome is that Gnucap becomes a novel simulation 
kernel and people/schools/companies/organizations can build an ecosystem 
around these plugins?

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