[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:03:20 -0400 (EDT)

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): added libtoolize --ltdl (run me first!)
        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/'s -export-dynamic flag.
        AM_CPPFLAGS is more modern that INCLUDES
src/ the core of gnucap, for now, this includes
                everything but and the model files. 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, linking against own libgnucap
                shared lib by default.
        added 'dlopen' command/class, similar to 'attach'.
                calls lt_dlopenext() instead of dlopen().
        calls to ltdl_init(), ltdl_exit()

I don't know if this is how you wanted the gnucap core library organized, factoring out 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
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.


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

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

reply via email to

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