>>> "Braden" == Braden McDaniel <[EMAIL PROTECTED]> 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 _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool