Ralf Corsepius <[EMAIL PROTECTED]> writes: > This would require to change all packages providing aclocal/ macros of > their own, i.e. is not feasible at present time, IMHO.
It can be done slowly if you continue to search datadir/aclocal for now, and also search the versioned directories. Just deprecate datadir/aclocal if the decision is that macros must be for a specific version. > Example: > If gtk.m4 was installed to share/aclocal-1.4, all packages applying > gtk.m4 were coupled to automake-1.4. > If gtk.m4 is automake-1.4 and automake-1.5-compatible, and gtk.m4 can be > applied with automake-1.4 and automake-1.5 I don't see how this is avoidable. Either a) m4 macros can be written which work with all autotools, in which case you can use any automake with gtk.m4 or b) m4 macros are autotool-version-specific, in which case packages must use only autotools that gtk.m4 explicitly supports. The problem with a) is that it requires seeing the future, or locking down the "ABI" of autotools. The problem with b) is that sometimes it happens that a new autotools version does work with an old macro, even though it isn't really the policy of either GTK or autotools that it should, and people want to take advantage of this accident. I can imagine autotools looking for an "old" macro if a new one isn't found, perhaps, which would let people use the accidental-compatibility. Or maybe packages should always install their latest m4 to datadir/aclocal in addition to the versioned locations, in the hope that new autotools will be able to use it. I don't know. The strong opinion I have here is that it's broken to rely on a) without actually guaranteeing that a) is going to work. i.e. you can't just have one datadir/aclocal but no fixed definition of what kind of macros are in there. It's important to define a policy. > Right, here the problem is _autoconf_ and I don't see any way around > fixing these macros. > > [Many gnome macros are not autoconf-2.5x compatible => I don't see any > alternative to fixing them.] That's a separate issue from patching automake. (As an aside, fixing for autoconf 2.5x has been much simpler than fixing for automake 1.5, for whatever reason. The only thing it seems to require so far is adding extra [] quotes in certain places.) > > Something like GTK would probably install m4 to several different > > share/aclocal-1.x directories, to avoid imposing a specific automake > > version on programs using GTK. > IMO, this can't work, because installing third-party macros is subject > of a package's configuration and currently is out of control of > automake. It's in the control of someone who can fix things. It's not automake's job to fix other packages; it's automake's job to provide a mechanism and policy whereby other packages have a Right Thing they can do. Sharing datadir/aclocal between all packages means the Right Thing is for all packages on a system to use the same version of automake; and that truly is something out of the control of any individual maintainer, which I think is holding up automake 1.5 adoption. > Having thought further about your proposal, am inclined to think that > versioning share/automake is also required and that, if share/automake > was versioned, putting automake's own m4-macros to somewhere therein > would probably be better. Right, I did version share/automake - I should have mentioned that. You're right it may well make sense that if we say datadir/aclocal-1.4 is a location for third-party macros, that the automake-internal macros should not also go there. Havoc
