Ralf Corsepius <[EMAIL PROTECTED]> writes: > 2. I am not sure if recommending share/aclocal-<version> for third party > macros is a good idea: > * Currently hardly managable on the user-side => If at all, then some > auto*tool should installing *.m4's to share/aclocal-<version> > automatically (data_ACLOCALS = foo.m4 ??)
If we only get a new incompatible version every 9-12 months or so I think it's pretty manageable. If there's an incompatible version every two months it's a mess, but there are other reasons breaking compat every two months isn't such a great plan. ;-) > * share/aclocal macros can be (and currently are supposed to be) > compatible to several versions of auto*tools. If you want to commit that share/aclocal macros will never break then it works. But I don't think saying they "mostly won't break sort of" is really addressing the problem. > Installing third party macros to aclocal-<version> would > unnecessarily tie these to a particular set of autotools and raise > further problems if later used with other packages' configurations. One solution is to have an unversioned fallback location where all aclocal versions search. In fact you really need share/aclocal to be that location just for historical reasons, as in my patch. Alternatively, aclocal could always look in the locations for past versions in addition to the location for its current version, on the principle that finding an old macro is better than finding no macro. (But it should not look in the locations for newer versions, obviously.) Perhaps aclocal would warn if the macro version was outdated. Havoc
