Re-using bootstrap in the half-strap

Re-using bootstrap in the half-strap

[Christopher Allan Webber]

Hello,

A thought this morning... one challenge with Guile's 2.1 branch is it
takes a lonnnng time to bootstrap.  There are good reasons for this, and
Andy Wingo has documented them:

  http://wingolog.org/archives/2016/01/11/the-half-strap-self-hosting-and-guile

However, I can't help but wonder if we could reuse the initial
bootstrapped compiler.  What if we had an external package that
contained *just* the scheme interpreter used to bootstrap the rest of
the system?  We might not need to separate the codebase, but have this
be a separate make output.

If you could package *just* the bootstrapped compiler, if a user doesn't
feel like waiting through the whole bootstrap process, they could use
the existing bootstrap package, like:

  ./configure --with-bootstrap=/path/to/guile-bootstrap

and maybe we could have a guile-bootstrap package in guix, etc.  If you
want to do the whole bootstrap yourself in the Guile package, you could
do so, but it wouldn't be a requirement, assuming you had that separate
package...

Thoughts?  Useful?  Badly informed?
 - Chris

Re: Re-using bootstrap in the half-strap

[Mathieu Lirzin]

Hello,

Christopher Allan Webber <cwebber@dustycloud.org> writes:

> A thought this morning... one challenge with Guile's 2.1 branch is it
> takes a lonnnng time to bootstrap.  There are good reasons for this, and
> Andy Wingo has documented them:
>
>   http://wingolog.org/archives/2016/01/11/the-half-strap-self-hosting-and-guile
>
> However, I can't help but wonder if we could reuse the initial
> bootstrapped compiler.  What if we had an external package that
> contained *just* the scheme interpreter used to bootstrap the rest of
> the system?  We might not need to separate the codebase, but have this
> be a separate make output.
>
> If you could package *just* the bootstrapped compiler, if a user doesn't
> feel like waiting through the whole bootstrap process, they could use
> the existing bootstrap package, like:
>
>   ./configure --with-bootstrap=/path/to/guile-bootstrap
>
> and maybe we could have a guile-bootstrap package in guix, etc.  If you
> want to do the whole bootstrap yourself in the Guile package, you could
> do so, but it wouldn't be a requirement, assuming you had that separate
> package...
>
> Thoughts?  Useful?  Badly informed?
>  - Chris

I feel the same way.  I don't know about the technical details, but
such convenience would be more than welcome.

Thanks,

-- 
Mathieu Lirzin

Re: Re-using bootstrap in the half-strap

[Ludovic Courtès]

Hi!

Christopher Allan Webber <cwebber@dustycloud.org> skribis:

> If you could package *just* the bootstrapped compiler, if a user doesn't
> feel like waiting through the whole bootstrap process, they could use
> the existing bootstrap package, like:
>
>   ./configure --with-bootstrap=/path/to/guile-bootstrap

That’s essentially what happens when cross-compiling Guile, where the
GUILE_FOR_BUILD variable must point to a same-version Guile.

What you’re suggesting seems equivalent to bundling the pre-built .go
files, which is what is done with release tarballs.

Or am I missing something?

Thanks,
Ludo’, who sympathizes.  :-)

Re: Re-using bootstrap in the half-strap

[Christopher Allan Webber]

Ludovic Courtès writes:

> Hi!
>
> Christopher Allan Webber <cwebber@dustycloud.org> skribis:
>
>> If you could package *just* the bootstrapped compiler, if a user doesn't
>> feel like waiting through the whole bootstrap process, they could use
>> the existing bootstrap package, like:
>>
>>   ./configure --with-bootstrap=/path/to/guile-bootstrap
>
> That’s essentially what happens when cross-compiling Guile, where the
> GUILE_FOR_BUILD variable must point to a same-version Guile.
>
> What you’re suggesting seems equivalent to bundling the pre-built .go
> files, which is what is done with release tarballs.
>
> Or am I missing something?
>
> Thanks,
> Ludo’, who sympathizes.  :-)

I'm suggesting we don't bundle them *with* it... because that wouldn't
be helpful when building from a git checkout.  But if we could point to
the prebuilt .go files from a separate package, then yeah!

Note that I wouldn't want to *require* building from a separate
package... I agree that it's valuable to be able to not rely on Guile to
build Guile :)

But maybe I'm just being silly!
 - Chris