> From: Havoc Pennington <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: automake parallel install stuff > Date: 08 Jan 2002 18:34:50 -0500 > > > Hi, > > I'm wondering if we could convince you and the autoconf guys to think > about making incompatible autotools releases install in parallel. Good idea, but ..
> I > just patched the Red Hat Linux automake RPMs to work this way, the > patches are very simple. Well, AFAIS, these patches help to some (IMHO: questionable) extend but miss some (IMHO) important issues (cf. below). > I'm appending them. (In the tarballs you'd > also need to change the Makefile.am to rename the install directories, > I did that via "mv" in the spec file to avoid re-running automake in > the automake specfile, which was just too complicated for me. ;-)) > Also, in the spec file I rename automake to automake-1.4, aclocal to > aclocal-1.4, automake to automake-1.5, aclocal to aclocal-1.5, and > symlink automake to automake-1.5. I provide versioned executables in > both RPMs because those are probably the best ones for other packages > to refer to - so the packages won't need to be changed when > automake-1.6 appears and gets the "automake" symlink. > > Parallel install is really important > [..] > > We're seeing the same thing in GNOME - if packages could port to > 2.53/1.5 piecemeal, then they'd all be ported already, but as it > stands you have to port every module in GNOME at once or it's > impossible to compile GNOME as a whole on one machine anymore, and no > one wants to port every module in one go. So the barrier to entry for > 1.5 is really high. > > If we could get the parallel install moved upstream, then we could > count on everyone being able to install both versions and upstream > packages could reference the "automake-1.5" executable. The issue you are about to fix/work-around is not mixing automake's own m4-macros, but your patches are missing further, IMHO even worse important issues. >From my experience, at present time, the main cause of autotool-problems is incompatibilities between autoconf-2.13 and autoconf-2.5x (esp. "underquoting" and canonicalization), then gettext (E.g. gettextize's habit to edit ChangeLogs - renders autogen.sh-scripts almost useless), then libtool (1.4.2 pulling in C++, 1.3: ltconfig.sh) followed by automake in last place. One significant portion of these autotool-version related problems actually stem from using autoconf-2.52-incompatible m4-macros distributed with packages and installed to share/aclocal (eg. gnome-macros, gtk.m4). I.e. even with your patch applied, autotools will continue to fail on GNOME-modules if using the wrong version of autotools, because some of the macros in aclocal/ depend on using _one_ certain version of _autoconf_ and will not help at all wrt. libtool(ize) and gettext(ize), while the impact of using a specific version of _automake_ is close to zero. => 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). Ralf
