Re: libtool macros installed in pkgdatadir?

[Alexandre Duret-Lutz]

>>> "Braden" == Braden McDaniel <address@hidden> writes:

[...]

 Braden> Right... But aclocal pulls them from a standard location on the
 Braden> system. While this means the distribution may be colored by
 Braden> characteristics of the system where it's built, it does mean that in
 Braden> general package maintainers aren't responsible for maintaining the
 Braden> macros they're using.

Yes.  The maintenance argument applies better to custom macros
(e.g., maintaining acinclude.m4 is a pain).

However lumping everything in aclocal.m4, also means users or
developers cannot rebuild aclocal.m4 unless they have the macro
installed.  It don't happen if the macro is separately
distributed.

The `Local Macros' node of the Automake 1.8 manual discusses
both issues.

[...]

 Braden> What I *am* concerned with is the prospect of having manually to copy
 Braden> the file with PKG_CHECK_MODULES (for instance) to my project's
 Braden> directories each time the system pkg-config is upgraded in order to
 Braden> ensure parity. I'm also concerned that other users of my project's CVS
 Braden> repository would have to do the same. Pushing "my" PKG_CHECK_MODULES
 Braden> into my CVS repository is not a solution, as there may be a version
 Braden> mismatch with the version of pkg-config on another user's system.

The plan is to have this copy performed automatically by the
aclocal replacement.  As aclocal is slowly moving towards its
replacement (which cannot exist yet because it requires M4
support), a next aclocal version may even include a --copy or
--update option to try this behavior.

Anyway, the point is that you should not fear this.  Installing
third-party macros in /usr/share/aclocal will continue to work.
-- 
Alexandre Duret-Lutz