[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: automake parallel install

From: Havoc Pennington
Subject: Re: automake parallel install
Date: 13 Jan 2002 11:45:12 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1

Alexandre Duret-Lutz <address@hidden> 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
>'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'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
>  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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]