[Top][All Lists]
[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
- a few questions, Thomas Vander Stichele, 2002/02/07
- Re: a few questions,
Alexandre Duret-Lutz <=