[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: Mon, 15 Jun 2009 01:37:36 -0400 (EDT)

I'd be very interested in helping with this effort. The last time I did anything about it was a few years ago, until I got distracted with school (a rather long distraction, at that). Is the latest snapshot a good place to start, or has there already been some work offline?

On 6/8/2009 7:44 PM, al davis wrote:
On Sunday 07 June 2009, Kevin Bowling wrote:

I would like to fix up the autotools build system and address
any short comings Gnucap is having.  You've said before that
it is broken or not optimal.  Can you list any specific
cases?  I will post patches to the list when this work is

In spite of that, I acknowledge the need for it, and feel that
for now there is no alternative, as I look with trepidation at
updating the gnucap autoconf system as is needed for plugins.
   What is needed now is update of both versions to properly handle
plugins.  Also needed is a refactoring of code separating core,
includes, main, and plugins.

Indeed, autotools are not a magic bullet. However, maintaining our own build system seems unnecessarily time consuming. It also will make it hard for users to build Gnucap on platforms we don't have access to. A lot of this comes free with auto*.

I've still been using autotools actively over the years; I'm more than happy to help write or test. But yes, architecting the organization of features is paramount, regardless of build system.

Having two build systems is both confusing to users/developers and cumbersome. My vote is to take the time now and fix one or the other, and only carry it in the default package. I have confidence that autotools can be made to work since many complex projects make use of it.

Henrik suggested making most of the core a library, with a very
minimal main program.  I agree that we need to do at least what
Henrik suggested, most likely more.  Since we are rearranging
anyway, it is probably appropriate to do it now.

These two items need to be elaborated on. Do you have any idea what parts you'd like to handle, and what others might do so we are not stepping on toes? Perhaps we can do task assignments with a system like I am using to run the + project, or something else if you prefer (Gnucap wiki?).

I consider choosing which plugins to static link to be something
a regular user building the program should be able to do.  This
is not supported by autotools as far as I know.

Is there a compelling reason to force plug-ins to link statically? They work very well dynamically. Won't configure --disable-shared do the trick?

I believe we can set conditionals.  For example, in

AM_CONDITIONAL(STATICPSS, test "$enable_staticpss" = yes)

When the user specifies ./configure --enable-staticpss, this variable will be passed to the Makefile.

In the plugin directory's (gnucap/plugins/pss):

lib_LIBRARIES = libpss.a
libpss_a_SOURCES =

In the main
gnucap_LDADD += $(top_builddir)/plugins/pss/libpss.a
gnucap_CPPFLAGS += -I $(top_builddir)/plugins/pss/pss.h

And you might list conditional dependencies (libtoolized) like:

so the tools know statically, the set of all possible libraries.

This is a bit simplified, but I think a solution using something like this would be elegant. We would need to set defaults for which modules to build, but could also parse --disable-<x> statements to remove core static modules.

For features, AC_ARG_ENABLE lets you declare defaults in the optional trailing argument. As does AC_ARG_WITH, for dependencies.

The installation needs to produce something like this:
- a main executable, installed where executables normally go.
- includes, installed where includes normally go
- plugins available system-wide, intalled like libraries.

I would recommend pushing plug-ins into pkglibdir, to make it clear that they go with gnucap. (I even do this for regular shared libraries.) I also push include headers down a directory, into pkgincludedir, to minimize clutter in the installed space. It makes it easier to isolate include paths per package. A bin_SCRIPT like 'gnucap-config' would report the locations of these files accordingly (--cflags, --libs).

Seems easy enough by making use of PREFIX and such during make install and directing files where they need to go.
- each plugin must be considered separately

How will dynamic plugins compare with static? I suppose the conditional system could be used here as well. They would be dumped in {PREFIX}/{LIBDIR}/gnucap.
- a simple way to build user plugins with a simple Makefile
- a place for things like and the plugin Make2.

Can you elaborate details on these requirements.
Is this enough to get you started?

Yes. It looks like we will have to discuss my questions and comments before proceeding.


Eager to hear further developments!


David Fang

reply via email to

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