[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: Sun, 14 Jun 2009 15:06:12 -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/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*.

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

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


reply via email to

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