This is the mail archive of the automake@gnu.org mailing list for the automake project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: automake parallel install stuff



Ralf Corsepius <corsepiu@faw.uni-ulm.de> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]