[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: Fri, 19 Jun 2009 19:42:45 -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/19/2009 6:19 PM, al davis wrote:
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

With a plain Makefile, I would just edit the Makefile to add the
files I want to include.

On Sunday 14 June 2009, Kevin Bowling wrote:
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.

You can't list the plugins in the main Makefile.  You can't know
the entire list of possible plugins.

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.
Hi Al,

I deferred to Diego Pettenò of the Gentoo Linux project (among many others). He is an expert on packaging and building GNU software. He is heavily involved with the Xine project. If you know about multimedia, Codecs are basically plugins that the build file might not know about at runtime, just as you said we need in Gnucap.

Introduction aside, he is publishing a fantastic autotools guide: When I discussed the requirements of Gnucap with him, he did a blog post about plugins vs. builtins for everyone to see:

I don't think your buildsystem is bad by any means, so I asked Diego for advice on choosing how to proceed. He stated essentially "its not about the developers, but rather the distributions" Supporting hundreds of custom build systems must truly be a nightmare. Like it or not, autotools is the de facto system for GNU software.

The average user should be able to simply install Gnucap from their distro of choice (Fedora and Gentoo already do this -- I checked Gentoo and they use the autotools build. I'd bet the SRPMs of Fedora are the same). We make that easier by sticking to the standards.

Again, I don't think there is anything we are doing that can't be handled by autotools. In fact, it should keep things seemless when building across platforms like Mac OS X that do libraries completely differently. I'm interested in improving Gnucap, not handling bizarre build quirks in operating systems I don't care about.

Kevin Bowling

reply via email to

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