|
From: | Braden McDaniel |
Subject: | Re: libtool macros installed in pkgdatadir? |
Date: | Wed, 28 Jan 2004 18:41:18 -0500 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 |
Scott James Remnant wrote:
On Wed, 2004-01-28 at 22:26, Albert Chin wrote:On Wed, Jan 28, 2004 at 10:13:21PM +0000, Scott James Remnant wrote:One day a version of Autoconf will use these, but for now when you run aclocal it'll add an "m4_include" line to aclocal.m4 for each of these files (rather than including them verbatim).Ugh. So *every* package providing useful 3rd-party autoconf macros must be copied locally to the package using them?This is exactly what happens now, aclocal does exactly this. Every third party macro set gets copied locally into the package using it, just into one great big unmanangeable file called aclocal.m4.
Right... But aclocal pulls them from a standard location on the system. While this means the distribution may be colored by characteristics of the system where it's built, it does mean that in general package maintainers aren't responsible for maintaining the macros they're using.
By giving this kind of thing to individual packages to maintain and worry about, for example through autopoint and libtoolize (which both do this now) -- better tracking is provided, you know that the m4 macros you're relying on *haven't changed*.
In general I don't care about whether they've changed, as long as they work. If they don't work, I'll discover that in short order. In all likelihood, breakage with a new version of the macro is indicative of other problems with the new version of the dependency.
Which will of course mean that every time random package changes its macros, it *WON'T* break your configure script :-)
In four years of using the autotools, I can't say this has been much of a problem.
Having a directory of individual files rather than lumping them together in aclocal.m4 is more manageable.
If I'd ever had a reason to manage these macros, I might be more concerned with that.
What I *am* concerned with is the prospect of having manually to copy the file with PKG_CHECK_MODULES (for instance) to my project's directories each time the system pkg-config is upgraded in order to ensure parity. I'm also concerned that other users of my project's CVS repository would have to do the same. Pushing "my" PKG_CHECK_MODULES into my CVS repository is not a solution, as there may be a version mismatch with the version of pkg-config on another user's system.
It's not really that big a change result-wise, it's just a much cleaner way of doing things.
Perhaps I'm missing something, but it doesn't seem that way to me. Braden
[Prev in Thread] | Current Thread | [Next in Thread] |