[gentoo-dev] dev-lisp

[gentoo-dev] dev-lisp

[Karl Trygve Kalleberg]

Hi gang.

I'm going to celebrate my newfound gentoo developer status by not doing
anything on gentoo at all this weekend. I'm heading out of the country for
a much-earned relaxation weekend in the Scottish highlands.

When I get back, I'm going to suggest we make a dev-lisp category. I have
two working ebuilds for that category currently: ecls-0.2 and gcl-2.4.0

I'm working on sbcl and cmucl, but here is a small problem: Neither sbcl
nor cmucl can be bootstrapped from C (or any lisp implementation we can
compile using only the C compiler). sbcl must be bootstrapped from itself
of cmucl. cmucl must be bootstrapped from itself.

What this means is that to install cmucl og sbcl, we have to first get an
x86 binary for the particular compiler, then run that as the bootstrapping
compiler.

This primarily means we will fetch and run a binary, which I don't think
is being done anywhere (except if you consider the gentoo build iso
itself as a bootstrap) until now, and that this binary will only run on
x86.

I don't necessarily see a problem with this, but it's a bit different from
all the other packages we have.

Comments, suggestions ? (I'll read them when I get back on sunday
evening).

(In the distant future, sbcl might be able to bootstrap on ecls, and cmucl
might be able to bootstrap on sbcl, so we could theoretically built it all
completely from sources for the die-hard purists, but don't hold your
breath.)

Regards,

Karl T

Re: [gentoo-dev] dev-lisp

[Daniel Robbins]

On Fri, Aug 03, 2001 at 04:07:30AM +0200, Karl Trygve Kalleberg wrote:

> This primarily means we will fetch and run a binary, which I don't think
> is being done anywhere (except if you consider the gentoo build iso
> itself as a bootstrap) until now, and that this binary will only run on
> x86.

This isn't a problem.  It would be nice if we could install the pre-compiled
binaries inside /tmp/portage, use them only for bootstrapping, and then throw
them away afterwards.  But if that's not possible, I guess we can create 2
packages: foo and foo-bin.  foo can then have foo-bin in its DEPEND, and can
potentially even overwrite foo-bin on merge.

Best Regards,

-- 
Daniel Robbins					<drobbins@gentoo.org>
Chief Architect/President			http://www.gentoo.org 
Gentoo Technologies, Inc.			

Re: [gentoo-dev] dev-lisp

[Dan Armak]

On Friday 03 August 2001 05:07, you wrote:
> Hi gang.
>
> I'm going to celebrate my newfound gentoo developer status by not doing
> anything on gentoo at all this weekend. I'm heading out of the country for
> a much-earned relaxation weekend in the Scottish highlands.

If you haven't yet, please move the ebuilds you submitted here from incoming 
to their rightful places and grab their items on dev-wiki. There's only one 
left there I think, python-docs.


-- 

Dan Armak
Gentoo Linux Developer, Desktop Team
Matan, Israel

Re: [gentoo-dev] dev-lisp

[Karl Trygve Kalleberg]

On Fri, Aug 03, 2001 at 10:18:29AM +0300, Dan Armak wrote:

> If you haven't yet, please move the ebuilds you submitted here from incoming 
> to their rightful places and grab their items on dev-wiki. There's only one 
> left there I think, python-docs.

Chadh already grabbed this one. 

Also, would it not be a good idea for another team member than the
original submitter to grab the item and do the actual verification and
move ?

This way, we get at least a minimum of "code-review" before the script is
sent off into the dangerous Real World.


Regards,

Karl T

Re: [gentoo-dev] dev-lisp

[Terje Kvernes]

Karl Trygve Kalleberg <karltk@prosalg.no> writes:

> When I get back, I'm going to suggest we make a dev-lisp category. I
> have two working ebuilds for that category currently: ecls-0.2 and
> gcl-2.4.0

  thank you!
 
> I'm working on sbcl and cmucl, 

  greatness, cmucl will be nice to have around as well.

> but here is a small problem: Neither sbcl nor cmucl can be
> bootstrapped from C (or any lisp implementation we can compile using
> only the C compiler). sbcl must be bootstrapped from itself of
> cmucl. cmucl must be bootstrapped from itself.

  heh, been there, done that. (and yes, I got the tshirt. ickyness).
   
-- 
Terje