Re: [Gnucap-devel] Autotools build system

[David Fang]

Hi again,

Attached is an initial patch (-p1) against your 2009-06-11 snapshot that 
libtoolizes the build, among other things (I'll explain each piece):

autogen.sh: added libtoolize --ltdl (run me first!)
configure.ac:
        AC_CANONICAL_HOST check for characteristics of platform,
                needed by libtool macros.
        AC_LIBLTDL_CONVENIENCE build against distributed libltdl,
                which is bundled with gnucap after libtoolize.
                This is common practice, as it doesn't require the
                user to have libltdl pre-installed.
        AC_DISABLE_STATIC (optional) just build for shared libraries
                only to cut compilation time in half.
        AC_CONFIG_SUBDIRS -- libltdl has its own config
        LTDL_SHLIBPATH_VAR -- often DYLD_LIBRARY_PATH, but may vary
                on different platforms.
        removed -rdynamic, as it is not portable, and is replaced by
                src/Makefile.am's -export-dynamic flag.
modelgen/Makefile.am:
        AM_CPPFLAGS is more modern that INCLUDES
src/Makefile.am:
        libgnucap.la: the core of gnucap, for now, this includes
                everything but main.cc and the model files.
        gnucapbasemodels.la: the base plug-in that contains
                all of the models distributed with gnucap.
        replaced pattern rules with real suffix rules for
                Makefile portability, retained dependencies.
        gnucap: reduced to main.cc, linking against own libgnucap
                shared lib by default.
src/c_attach.cc:
        added 'dlopen' command/class, similar to 'attach'.
                calls lt_dlopenext() instead of dlopen().
src/main.cc:
        calls to ltdl_init(), ltdl_exit()

I don't know if this is how you wanted the gnucap core library organized, 
factoring out main.cc was just a guess.
I validated that the package as a whole still works by running 'make 
distcheck'.

With this build, even the base models are not loaded on startup by gnucap!
On startup, one can load the base models:

from $(builddir)/src/:
$ ./gnucap
gnucap> dlopen gnucapbasemodels
gnucap> ...

gnucap> attach gnucapbasemodels.so
also works, but depends on the local system's plug-in extension.

(Does everything still work as expected for you after loading 
gnucapbasemodels?)

*After* installation however, the env. var. DYLD_LIBRARY_PATH is used to 
search for plug-ins by lt/dlopen().  Alternatively, we could have 
libgnucap automatically prepend the $(pkglibdir) (where plugins are 
installed) to the ltdl search path (call ld_dladdsearchdir), so the user 
need not modify the environment, as long as plug-ins are installed to 
$(pkglibdir).

What I haven't done yet:
I haven't built any of the other separately distributed models yet, I have 
another proposal for them after we review this patch/ideas.


Other notes: do you plan to turn your examples dir into a test-suite (mke 
check)?  It seems users can already run them.

Documentation: If you have the sources for the html documentation I've 
found online, were you planning on distributing them?  perhaps as texinfo? 
Texinfo is great for producing html/pdf/info docs from the same source. 
automake has support for handling texinfo sources.  You can also 
distribute pre-built documentation so the user need not build it.

Fang


> > This rule applies to the program source too.  The core has no
> > listing of what plugins might be used.
> > The only way I can think of to let the user specify what plugins
> > to static link is to let the user explicitly list  them,
> > somewhere, or to include a file containing such a list.
>
> 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
>
> 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.
>
> 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).

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

gnucap-2009-06-11.patch
Description: Text document