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
know.
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
configure.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 Makefile.am (gnucap/plugins/pss):
if STATICPSS
lib_LIBRARIES = libpss.a
libpss_a_SOURCES = pss.cc
endif
In the main Makefile.am:
if STATICPSS
gnucap_LDADD += $(top_builddir)/plugins/pss/libpss.a
gnucap_CPPFLAGS += -I $(top_builddir)/plugins/pss/pss.h
endif
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:
http://www.flameeyes.eu/autotools-mythbuster/index.html. When I
discussed the requirements of Gnucap with him, he did a blog post about
plugins vs. builtins for everyone to see:
http://blog.flameeyes.eu/2009/06/18/plugins-and-builtins-what-s-the-best.
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.
Regards,
Kevin Bowling
_______________________________________________
Gnucap-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnucap-devel
