[Top][All Lists]

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

[bug#38390] [bug #38390] Building bootstrap Gash and Gash-Utils

From: Ludovic Courtès
Subject: [bug#38390] [bug #38390] Building bootstrap Gash and Gash-Utils
Date: Wed, 05 Feb 2020 22:33:53 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)


Timothy Sample <address@hidden> skribis:

> Ludovic Courtès <address@hidden> writes:


>> Woow, that is very nice!  So all of a sudden there’s an extra bunch of
>> binary seeds we can get rid of, woohoo!  I didn’t expect that even bzip2
>> and xz would be implemented.
> I don’t think we could get rid of any binaries just yet.  We need Guile
> to run Bootar and we can’t get Guile without the statically linked
> “tar”, “xz”, “mkdir”, and “bash”.  This just removes some references to
> them.  Although, it occurred to me that we could get something like
> Bootar (perhaps further simplified) to run on Mes, in which case we
> could use a statically linked Mes to unpack and wrap Guile.  That would
> let us get rid of “%bootstrap-executables”.  (Note however that I tried
> running Bootar in Mes for fun, and the extractor script – once it was
> simplified – caused a segfault.)

Oh cool.  Being able to run Guile code on Mes sounds like a worthy goal
longer-term anyway, so hopefully we’ll get there!

> BZip2 and XZ just barely work, by the way.  I implemented BZip2, but I
> skipped over all the CRC checking.  XZ has a bug when called with input
> from stdin, which is how Gash-Utils tries to call it.

Heh, not so bad.

>>> +(define (make-bootstrap-phases version scripts modules)
>>> +  "Create a form that modifies the standard GNU build phases so that
>>> +they build simple Guile programs using only the bootstrap Guile.  The
>>> +'.in' files in the directory MODULES are configured with VERSION, the
>>> +'.in' files in the directory SCRIPTS are configured with the bootstrap
>>> +Guile and its module and object directories, and the Scheme files in the
>>> +directory MODULES are compiled and installed."
>>> +  `(modify-phases %standard-phases
>>> +     (replace 'configure
>> Should this be factorized out in a (guix build gnu-bootstrap) module or
>> similar?  That would keep build-side code separate and would avoid
>> making ‘commencement.scm’ bigger.
> I would be happy to do that.  It’s nice having everything in one place,
> but having a bootstrap build system would certainly make the packages
> clearer.  I suppose it could also get rid of the implicit inputs for us
> and use “%bootstrap-guile” by default.

I doesn’t have to be a full-blown build system, because there might be
as much boilerplate as actual code, but simply moving the definitions of
phases in a separate file could help keep commencement.scm clear.

>> I guess the only thing that remains to be done is changing the temporary
>> URLs to the self-extracting script & co., right?
> Yup.  I’ll release both packages soon.

Great, thank you!


reply via email to

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