a few questions

[Thomas Vander Stichele]

Hi,

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

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.

Thanks,
Thomas

-- 

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/