automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: a few questions


From: Alexandre Duret-Lutz
Subject: Re: a few questions
Date: 09 Feb 2002 18:47:11 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

>>> "Thomas" == Thomas Vander Stichele <address@hidden> writes:

[...]

 Thomas> In most cases you use the .m4 macro installed with the
 Thomas> -devel package of the library.  Since we cannot expect
 Thomas> every GStreamer developer to have all libraries and
 Thomas> -devel packages that could possibly used with it, we
 Thomas> ran into problems.  If you use the macros from these
 Thomas> -devel packages but you don't ship them, the autotools
 Thomas> will complain about undefined macros and this stumps
 Thomas> users.

 Thomas> So we started shipping .m4 files from these libraries
 Thomas> in a separate .m4 directory.  People have advised
 Thomas> against this but I don't really know how to solve this
 Thomas> otherwise.  I had one idea though, but I don't know if
 Thomas> it's possible : if there's a way to check if a macro is
 Thomas> already AC_DEFUN'd or not, I could implement fallback
 Thomas> macros that tell the rest of the configure not to
 Thomas> enable this plugin.  I don't know if that's possible or
 Thomas> not ?

... and whenever you make a new release you will have to make
sure those fallback macros have not been used accidentally?
IMHO, it's not worth the trouble, just ship the macros you use.
Doing so also allows one developer to make a fully-usable
release without having all the optional packages installed.

 Thomas> Anyway, what I also wanted to ask was: is it better to do
 Thomas> cat m4/*.m4 > acinclude.m4
 Thomas> or
 Thomas> aclocal -I m4 ?

 Thomas> In the second case, people get warnings that certain
 Thomas> macros are defined twice (since, for example, they have
 Thomas> the right .m4 on their system from their devel package,
 Thomas> and we supply another version of it).  

This was the behavior of Automake 1.4.
This is no longer the case today.

 Thomas> I'd like to avoid that of course, so I use the first
 Thomas> method.

 Thomas> The first method seems to have the disadvantage that it
 Thomas> prefers our supplied m4's, while it would be better to
 Thomas> prefer system-installed m4 macros.

aclocal will prefer the local m4/ macros over the system macros
too.  I fail to see why this is bad, but if it annoys you it's
easy to order the -I options to that effect:

  aclocal -I `aclocal --print-ac-dir` -I m4

[...]
-- 
Alexandre Duret-Lutz



reply via email to

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