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