Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: > This seems to be the minimum required to allow parallel installs > of Automake. However doing only this makes unsafe to use > versions installed that way, due to the rebuild rules issue you > pointed out: using automake-1.5 is useless if the resulting > Makefile.in's only call automake.
Coding "automake-1.5" into the rebuild rules and requiring that people re-run "automake" if they uninstall 1.5 seems pretty sane to me. > Maybe `automake' should not be a symlink but a script that > select the right automake version to use for a project. I heard Debian has had poor results with that, but I haven't tried it myself. It's probably hard to get right unless you can find some really reliable way to pick an automake. It would be neat if so. But speaking of Debian, they're another example of a distribution coming up with ad hoc solutions here - which is why I think an upstream solution would be better. e.g. for GNOME we want all our scripts and such to work on any distribution. GNOME, Red Hat, and Debian are all projects that coordinate large numbers of separate but interdependent software packages - I think that's why the issue comes up for us. It doesn't show up for someone maintaining only single standalone packages. > It's easy to write Makefile.am's that works with both Automake > 1.4 and 1.5. If some project requires 1.5 it can require it > using the '1.5' option. Ideally, Automake 1.5 users should to > be able to compile every project. Maybe it would be better to > focus on ensuring backward compatibility, rather than devising > something which will hide unwanted ABI breakage. Back compat is a fine solution, but it has to be better back compat than 1.5 actually has. Many packages in Red Hat Rawhide have "issues." Almost back compat doesn't really suffice, especially given the difficulty of debugging Makefiles and m4-generated shell scripts (at least from the perspective of your average hacker). To me one of the virtues of parallel install is that it gives you a lot more freedom to break back compat when needed, because people can upgrade piecemeal on their own schedule. Also, people can test out devel versions without having to hose their system or use funky prefix tricks. > Havoc> or whether they have to be for a specific automake > Havoc> "ABI". > > I don't think such dependency exists. Third-party m4 macros are > usually dependent upon Autoconf, not Automake. I'm sure Akim > will write "aclocal should belong to Autoconf" if he posts a > message in that thread <wink>. > In some sense there must be an auto*-wide "ABI" including all of autoconf, automake, and libtool... as I said, I don't know how this is currently coordinated. But probably the policy/solution here should span all the tools. Havoc