[Top][All Lists]

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

Re: [Gnucap-devel] Autotools build system

From: Kevin Bowling
Subject: Re: [Gnucap-devel] Autotools build system
Date: Sat, 20 Jun 2009 21:39:00 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2

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

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

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

I have no problem with libtool.
Good :-).

reply via email to

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