Am Fre, 2002-01-11 um 03.52 schrieb Havoc Pennington: > > Ralf Corsepius <[EMAIL PROTECTED]> writes: > > => IMO, this patch is one alternative towards allowing parallel > > installation of _automake_, but does not help much wrt. the actual > > autotool-issues "Joe Occasional Installer" will meet (eg. when building > > GNOME modules). > > > > I agree there are other issues there, but the implication to me is > that we have to address those other tools as well as automake. We > still do have to address automake however. One step at a time. Not the worst approach ;)
> It's true that share/aclocal is not versioned and this creates > problems if third-party macros are dependent on specific versions. A > semi-solution here is for third-party macros to start using the > versioned share/aclocal-1.x directories instead. This would require to change all packages providing aclocal/ macros of their own, i.e. is not feasible at present time, IMHO. Furthermore it would render these macros not to be applicable for other packages which apply such macros. 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 > However leaving > share/aclocal in the search path works pretty well for now since most > third-party m4 seems to work with both automakes. 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.] > 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 annoying there that if an app > wants to upgrade automake they have to wait for a GTK release that > supports the new automake, but I see no way around that short of a > guarantee of back compat on the part of auto*. 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. Ralf
