[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):
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
- Re: [Gnucap-devel] Autotools build system, (continued)
- Re: [Gnucap-devel] Autotools build system, David Fang, 2009/06/20
- Re: [Gnucap-devel] Autotools build system, al davis, 2009/06/20
- Re: [Gnucap-devel] Autotools build system, David Fang, 2009/06/21
- Re: [Gnucap-devel] Autotools build system, al davis, 2009/06/21
- Re: [Gnucap-devel] Autotools build system, David Fang, 2009/06/21
- Re: [Gnucap-devel] Autotools build system, David Fang, 2009/06/21
- Re: [Gnucap-devel] Autotools build system, Kevin Bowling, 2009/06/21
- Re: [Gnucap-devel] Autotools build system, al davis, 2009/06/21
- Re: [Gnucap-devel] Autotools build system, Kevin Bowling, 2009/06/21
- Re: [Gnucap-devel] Autotools build system, David Fang, 2009/06/21
- Re: [Gnucap-devel] Autotools build system,
David Fang <=
- Re: [Gnucap-devel] Autotools build system, al davis, 2009/06/21
- Re: [Gnucap-devel] Autotools build system, al davis, 2009/06/21
- Re: [Gnucap-devel] Autotools build system, al davis, 2009/06/21
- Re: [Gnucap-devel] Autotools build system, David Fang, 2009/06/21
- Re: [Gnucap-devel] Autotools build system, al davis, 2009/06/21
- Re: [Gnucap-devel] Autotools build system, David Fang, 2009/06/21
- Re: [Gnucap-devel] Autotools build system, al davis, 2009/06/21
- Re: [Gnucap-devel] Autotools build system, David Fang, 2009/06/21
- Re: [Gnucap-devel] Autotools build system, David Fang, 2009/06/22
Re: [Gnucap-devel] Autotools build system, Kevin Bowling, 2009/06/17