[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
a few questions
Thomas Vander Stichele
a few questions
Thu, 7 Feb 2002 14:36:40 +0100 (CET)
I've recently gotten more involved with autoconf and automake because I
cleaned up build issues for GStreamer, a multimedia framework. I'm rather
new to autotools so I probably make a lot of mistakes along the way.
Anyway, I first have some questions on "the right thing to do".
First of all, regarding external .m4 macros. GStreamer works with plugins
which mostly depend on external libraries, mostly one at a time. In most
cases you use the .m4 macro installed with the -devel package of the
library. Since we cannot expect every GStreamer developer to have all
libraries and -devel packages that could possibly used with it, we ran
into problems. If you use the macros from these -devel packages but you
don't ship them, the autotools will complain about undefined macros and
this stumps users.
So we started shipping .m4 files from these libraries in a separate .m4
directory. People have advised against this but I don't really know how
to solve this otherwise. I had one idea though, but I don't know if it's
possible : if there's a way to check if a macro is already AC_DEFUN'd or
not, I could implement fallback macros that tell the rest of the configure
not to enable this plugin. I don't know if that's possible or not ?
Anyway, what I also wanted to ask was: is it better to do
cat m4/*.m4 > acinclude.m4
aclocal -I m4 ?
In the second case, people get warnings that certain macros are defined
twice (since, for example, they have the right .m4 on their system from
their devel package, and we supply another version of it). I'd like to
avoid that of course, so I use the first method.
The first method seems to have the disadvantage that it prefers our
supplied m4's, while it would be better to prefer system-installed m4
So my question is : what is the right way to tackle this problem ?
On another note, while getting fed up with GStreamer builds and it's
really long autogen/configure/make distcheck cycle I decided that it would
be a lot easier for me to learn autotools by creating boilerplate stuff
that only does one of the little configuration parts so that I get a much
shorter feedback cycle and actually enjoy learning autotools.
I decided to start a project around this and hopefully grow a few useful
macros from them as well to be used in other projects. It's called
Autostar Sandbox. Only stuff in CVS right now as I go along cleaning up
GStreamer. The (sparse) site is at http://autostars.sourceforge.net/
(Looking into moving it to Savannah).
If you ever get stumped fixing a build issue and not advancing quickly
enough, maybe consider implementing it in the same way in the autostar
sandbox and leave your results in there as well for others to learn from.
The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/
I know everybody here wants you
I know everybody here thinks he needs you
And I'll be waiting right here just to show you
how our love will blow it all away
<-*- address@hidden -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/
- a few questions,
Thomas Vander Stichele <=