Subject: Re: self bootstrapping packages?
To: None <tech-pkg@NetBSD.org>
From: Jon Buller <jon@Bullers.Net>
Date: 11/12/2007 20:07:32
Alan Barrett wrote:
> On Sun, 11 Nov 2007, Jon Buller wrote:
>> The only trouble was that SBCL needs a Common Lisp system to build itself.
> Is there any Common Lisp system written in C? If so, could SBCL have a
> BUILD_DEPENDS referring to it?
In theory Clisp could do the job, but it's always been a bit on the
> Similarly for lang/gcc*-ada: Is it possibly to set up a chain of depends
> such that gcc-ada depends on an older version of itself which depends
> on something that's written in C? (Last time I tried to research this
> issue, I found it too difficult to track down old versions of GNAT to
> check whether there was a path for bootstrapping it from a C compiler.)
> Even gcc-c has an issue similar to this: Current versions of gcc are
> written in C90, and can't be compiled with a K&R C compiler. We could
> set up a chain of dependencies so that a system that has only a K&R
> C compiler first builds gcc-2.x, then uses that to build the current
> version of gcc.
I don't think we want some almost infinitely long chain of dependencies
here. All you need is the last version to compile the next. So if you
keep a copy of the last binary in a package, you are all set, provided
the make install step doesn't gripe about the package being already
installed, or takes some action to work around it.
For gcc, we just overlook everything and expect a C90 compiler to
already be present, outside the package system. (Or at least in a
package that does not conflict with the package being built.) If we
could not depend on that, the SBCL situation would be exactly the same.
You would need a previous version of lang/gcc to be installed to build
the next version of lang/gcc. That is not the same as making lang/gcc
depend on lang/gcc3 which depends on lang/gcc-295 which depends on
lang/egcs which depends on... (Is the K&R compiler in a package? and
what is going to compile it?)
So my question is: Is this just a simple matter of adding a pre-install
target that deletes the previous package version (used to build the
current one), or is something more subtle required?