Re: Automake 2.50 migration strategy, as implemented
On Sun, May 27, 2001 at 12:43:47AM -0400, Ben Collins wrote:
> On Sun, May 27, 2001 at 12:35:34AM -0400, Steve M. Robbins wrote:
> >
> > Ben C,
> >
> > I don't find the sarcasm very convincing.
> >
> > I did not suggest special-casing a million things.
> >
> > I do think it is legitimate to consider the relative merits of the
> > various options when making a decision.
>
> But if I special case autoconf, then who knows what precedence that will
> set. It's not something I want to fathom.
I agree, it might set a precendent. However, it's not clear to me
that it will be a _bad_ precedent. It's a bit unfair to say that
special cases are bad "because it will set a precendent" while not
being willing to discuss what precise precendent you fear.
> Also, the case where the
> autobuilders will build things in a different environment than a normal
> user, or the maintainer would, is not acceptable. The autobuilders may
> be able to build it, but a normal user would have to know some secret
> (installing autoconf2.13) to get it to rebuild.
Philosophically, it is not ideal to have packages built in different
environments. Practically speaking, however, it is unavoidable: the
probability that any two human builders have the same environment is
rather small, I expect.
I think it is a bit of a myth that the autobuilders will produce
precisely the same sequence of bits that I get when I build a package.
For one thing, I might have libfoo-1.3.2 installed while the
autobuilder has libfoo-1.3.1. For another, if the package
build-depends on a virtual libbar-dev, I and the autobuilder might
build against completely different libraries. Worse: two different
autobuilders might choose different libraries to satisfy the same
virtual package.
The build daemons necessarily have some special knowledge built into
them. There must be, at least, a map specifying a real package for
each virtual package. The set of "build essential" packages is
another example of special knowledge. This list is not internal to
the build daemons, of course, but the fact that "build-essential" must
be installed *is* built in to them.
I don't see this knowledge represented in build daemons as a bad
thing. To the contrary, decent heuristics might enable more packages
to be built without human intervention (cutting down on the number of
failed autobuilder logs you'd need to look at). This information is
not hidden or lost: it is (or could be) available on-line for anyone
to see how to generate a given package for a given architecture.
It is a fact of life that software is a moving target, and build tools
are no exception. Although autoconf triggered this discussion, it is
a generic issue. You know as well as anyone that a libc revision can
have dramatic effects. Ditto for the X libraries, gcc (version 3 is
coming!), perl, etc.
Why wouldn't one want autobuilders that are more robust to such
changes? Putting the knowledge into the autobuilders is not just an
expediency; it also means that you solve the problem once in one
place, rather than giving all the package maintainers more busy-work
to do, checking whether the package will still build with the new tool
version.
-Steve
--
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants
Reply to: