RFC: fix configure spewage from PKG_CHECK_MODULES and others.
Christian Stimming
stimming at tuhh.de
Fri Jan 13 04:39:20 EST 2006
Derek Atkins schrieb:
> As I was looking at configure to handle the "qof issue" I thought I'd
> try to clean up a lot of the spewage that we get from "missing" .pc
> files when we're searching for various alternate packages. The problem
> is that this spewage comes from macros that we don't necessarily own...
>
> So my question to developers: Is it reasonable to pull in the macro
> into our own library and modify it in our own macro library? E.g.,
> is it okay if I pull pkg.m4 into our macro library and make changes there
> to silence it.. (a secondary question is whether aclocal will prefer
> our macros over system macros)..
I agree with your proposal. Many times those predefined autoconf macros
are simply not as well-thought as one would expect.
Also, we would only get out of sync if we depend on a radically new
version of the library which cannot be detected by old macros any
longer. But that would be obvious to the first developer who tries to
use the new library, who will then fix it by copying a newer autoconf
macro. So it's not something that would bite us silently.
As for aclocal preferring our macros: That is simply a question of the
"-I bla -I foo" arguments to "aclocal". Currently the highest priority
is given to the user's ACLOCAL_FLAGS (including directories from
GNOME2_PATH), second highest to our local macros/ directory, last
priority the standard aclocal directory. So as long as neither
ACLOCAL_FLAGS nor GNOME2_PATH is set, our macros are guaranteed to be used.
Christian
More information about the gnucash-devel
mailing list