Am Son, 2002-01-13 um 22.14 schrieb Tom Tromey: > >>>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: > > Tom> But I'm not as sure about renaming the executables by default. I > Tom> think I'd prefer to simply install as `automake', and let package > Tom> maintainers use `--program-suffix=-1.5' (or equivalent) in their > Tom> spec files. What do you think of that? > > Ok, now I'm convinced that we need to install the versioned > executables. It is the only way to get consistent results across all > platforms using the default install behavior. > > Tom> One issue is what we put in the rebuild rules in the Makefile. > > My current thinking is that we would name the installed version and > the install directories after the "install version". For anything in > the 1.5 series (1.5.1, 1.5-p1, 1.5c, whatever), this would be "1.5". > Then we would guarantee that for a given "install version" we would > only do bug fixes. > > So for instance you couldn't install 1.5 and 1.5.1 at the same time. > You'd simply have to upgrade in this situation. > > My rationale for this is that often you can use a slightly older > version. So forcing everybody to upgrade to 1.5.2 or whatever, unless > it is really required (something that can be specified in > AUTOMAKE_OPTIONS), is a bit unfriendly. Hmm, AFAIK, automake >= 1.5b requires autoconf >= 2.52, so such kind of situation probably will be inevitable once it will be released wrt. to autoconf.
> Any comments on this? > > Tom> I think the rebuild rule problem is even worse if autoconf is > Tom> versioned. Where will the version info come from? > > Still no solution here :-( May-be, I am going too far, but IMHO a drastic measure would help [I don't expect you to like this - This is just an ad-hoc thought without having thought about all the details and consequences :)]: 1. Merge the autoconf and automake packages into one package. This would - guarantee version-consistency between autoconf and automake. - solve the ownership problems (Does aclocal belong to autoconf? Is aclocal being part of automake just a historical relic/accident? IMHO, the answer to both is "yes") - allow using on common pkgdatadir instead of several ones. 2. Implement a "common driver" to all autotools (Similar to gcc being the driver to various other tools). This would: - Allow encapsulation of "autotools' components" - Allow implementing an internal versioning mechanism (automake -V version). - Ensure using a consistent set of "autotools' components" (Not bogusly picking up the wrong version) IMO, this would not be much different from what I'd consider a pragmatical approach: * Let autoconf be versioned similar to what is discussed for automake above. * Let automake check for the version of autoconf, automake is being configured with and hard-code this version into automake's files. This would tie one installation of automake to exactly one version of autoconf, without having the benefits merging automake and autoconf would have. Ralf
