Re: Creating a reliable bootstrap for building from source

Re: Creating a reliable bootstrap for building from source

[Jeremiah]

> What you are trying to do is even more heroic - bootstrapping all of
> guix :)

The real heros are those that check our work, report bugs and give us
insight into solving our most difficult problems.

And we LOVE patches and pull requests ;-D

> What I want is achievable, simply have the build system as a tested
> binary available. A tested builder package that is know to work
> against the current tree. We pretty much have it, it is only not
> formalized and tested on the build farm

If what you want is achievable and going to help, then please do it.
No need to ask, we always love people who take time to make things
better.

-Jeremiah

RE: Creating a reliable bootstrap for building from source

[Jeremiah]

> Thinking about it, what I want to achieve is that we can take the
> latest git tree and bootstrap by building guix and packages. This
> should be easy, since I have guix running, but it is not. And the main
> trouble is that the underlying build packages can differ over time. I
> am looking at gcc versions and guile versions.  I.e., we are building
> on shifting sands. How unguixy!

It is worse than that, Janneke and I are still trying to build out a
full source bootstrap.

Now mind you we have gotten quite a bit down that rabbit hole.
( I've build from a hex monitor to a Lexically scoped garbage
compacting/collecting lisp and Janneke built his rather impressive MES
which already supports large parts of the C language and enough to
bootstrap some rather important pieces)

But there still are many gaps left to close (how to bootstrap a 280 byte
hex monitor without a hex monitor or hex assembler, stage0-vm
downstrapping, MES tinycc bootstrapping, MES lisp bootstrapping, etc)

but ultimately shifting sands are the only grounds we can be certain
will be there.

So we better get comfortable minimizing our assumptions.

-Jeremiah

Re: Creating a reliable bootstrap for building from source

[Pjotr Prins]

On Sun, May 14, 2017 at 03:54:27PM -0400, Jeremiah@pdp10.guru wrote:
> > Thinking about it, what I want to achieve is that we can take the
> > latest git tree and bootstrap by building guix and packages. This
> > should be easy, since I have guix running, but it is not. And the main
> > trouble is that the underlying build packages can differ over time. I
> > am looking at gcc versions and guile versions.  I.e., we are building
> > on shifting sands. How unguixy!
> 
> It is worse than that, Janneke and I are still trying to build out a
> full source bootstrap.
> 
> Now mind you we have gotten quite a bit down that rabbit hole.
> ( I've build from a hex monitor to a Lexically scoped garbage
> compacting/collecting lisp and Janneke built his rather impressive MES
> which already supports large parts of the C language and enough to
> bootstrap some rather important pieces)
> 
> But there still are many gaps left to close (how to bootstrap a 280 byte
> hex monitor without a hex monitor or hex assembler, stage0-vm
> downstrapping, MES tinycc bootstrapping, MES lisp bootstrapping, etc)
> 
> but ultimately shifting sands are the only grounds we can be certain
> will be there.
> 
> So we better get comfortable minimizing our assumptions.

What you are trying to do is even more heroic - bootstrapping all of
guix :)

What I want is achievable, simply have the build system as a tested
binary available. A tested builder package that is know to work
against the current tree. We pretty much have it, it is only not
formalized and tested on the build farm.

Pj.
-- 

Ready for Guile 2.2!

[Ludovic Courtès]

Hello Guix!

Exciting times!

As of commit 608e42e7c92114497e7908980424288079acee1e, Guix builds with
Guile 2.2 (to be released sometime within the next 24 hours) and the
whole test suite passes.

All the dependencies of Guix except Guile-SSH (optional; use for
offloading and for ‘guix copy’) are already compatible with Guile 2.2.

Guile 2.2 comes with a new compiler and a new virtual machine.  As a
result, one of the main user-visible changes is that things are faster.

Building Guix with 2.2 is the first migration step.  The next steps are:

  1. Renaming ‘guile-next’ to ‘guile’ and making 2.2 the default.  Some
     packages (notably Guile-SSH, GDB, LilyPond) don’t work with 2.2 yet
     so for these we’ll change ‘guile’ to ‘guile-2.0’.  This can start
     as soon as this week.  :-)

     We’ll replace ‘package-for-guile-2.2’ with ‘package-for-guile-2.0’,
     though I don’t think it’ll make sense to keep both a 2.0 and a 2.2
     version of all the packages.

  2. Use 2.2 to build derivation, as the default #:guile-for-build
     (aka. ‘default-guile’.)  This can be done on the next
     ‘core-updates’ cycle and if everything goes well, it will be
     completely transparent.

Happy hacking!

Ludo’.

‘guix pull’ vs. transition to Guile 2.2

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 1930 bytes --]

Hello Guix!

ludo@gnu.org (Ludovic Courtès) skribis:

> As of commit 608e42e7c92114497e7908980424288079acee1e, Guix builds with
> Guile 2.2 (to be released sometime within the next 24 hours) and the
> whole test suite passes.
>
> All the dependencies of Guix except Guile-SSH (optional; use for
> offloading and for ‘guix copy’) are already compatible with Guile 2.2.

With the attached patch, the ‘guix’ package is built against Guile 2.2.
I’m running it on my GuixSD machine, and it works like a charm!

There’s a problem though, called “guix pull”.  ~/.config/guix/latest
currently contains 2.0 .go files.  Thus after reconfiguring GuixSD to
use Guix-for-2.2, running ‘guix’ typically gives loads of warnings like:

  ;;; WARNING: loading compiled file /home/ludo/.config/guix/latest/guix/derivations.go failed:
  ;;; ERROR: In procedure load-thunk-from-memory: No such file or directory

The fix is for ‘guix pull’ to build with Guile 2.2 when that’s what
we’re running.  For that, build-self.scm must be sure it can get the
‘guile2.2-ssh’ package when we’re on 2.2, or it will fail to compile the
new Guix.  However, ‘guile2.2-ssh’ appeared a day ago, so it’s missing
from most installations…

In short, ‘guix pull’ is broken in a way that may practically prevent it
from handling the 2.0-to-2.2 transition.  The risk is that ‘guix pull’
will fail to upgrade, preventing users from upgrading Guix altogether.
To work around that, people will have to use a Git checkout of Guix.  Of
course that’s what many of us already do, but still.

Maybe the upcoming release is a good time to make that transition: at
least people installing GuixSD or Guix from that release will already be
on 2.2 and won’t have problems from there on.

Thoughts? Ideas?

We all know it, but it’s really really time to fix ‘guix pull’…

Ludo’.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: the patch --]
[-- Type: text/x-patch, Size: 1849 bytes --]

From e7577d6e2499596b2d802f1a5be1f229ce2ab67f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= <ludo@gnu.org>
Date: Sat, 22 Apr 2017 15:13:36 +0200
Subject: [PATCH 1/3] gnu: guix: Build with Guile 2.2.

* gnu/packages/package-management.scm (guix-devel)[inputs,
propagated-inputs]: New fields.
---
 gnu/packages/package-management.scm | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/gnu/packages/package-management.scm b/gnu/packages/package-management.scm
index 952c268b0..bc2c1e0d3 100644
--- a/gnu/packages/package-management.scm
+++ b/gnu/packages/package-management.scm
@@ -52,6 +52,7 @@
   #:use-module (gnu packages tls)
   #:use-module (gnu packages ssh)
   #:use-module (gnu packages vim)
+  #:use-module (srfi srfi-1)
   #:use-module (ice-9 match))
 
 (define (boot-guile-uri arch)
@@ -69,6 +70,8 @@
                         "/20131110/guile-2.0.9.tar.xz"))))
 
 (define-public guix-0.12.0
+  ;; TODO: On the next release, move the Guile 2.2 inputs from 'guix-devel'
+  ;; to here.
   (package
     (name "guix")
     (version "0.12.0")
@@ -238,6 +241,17 @@ the Nix package manager.")
                  (base32
                   "0p4rh0629j89v4ka5dsp70a1xrfhg7sxjjq54p68vw7x5dkann4a"))
                 (file-name (string-append "guix-" version "-checkout"))))
+
+      ;; Build with Guile 2.2.
+      ;; TODO: Move to the stable 'guix' package on the next release.
+      (inputs
+       `(("guile" ,guile-2.2)
+         ,@(alist-delete "guile" (package-inputs guix-0.12.0))))
+      (propagated-inputs
+       `(("gnutls" ,gnutls/guile-2.2)             ;for 'guix download' & co.
+         ("guile-json" ,guile2.2-json)
+         ("guile-ssh" ,guile2.2-ssh)))
+
       (arguments
        (substitute-keyword-arguments (package-arguments guix-0.12.0)
          ((#:configure-flags flags)
-- 
2.12.2

Heads-up: transition to Guile 2.2

[Ludovic Courtès]

Hello Guix!

ludo@gnu.org (Ludovic Courtès) skribis:

> There’s a problem though, called “guix pull”.  ~/.config/guix/latest
> currently contains 2.0 .go files.  Thus after reconfiguring GuixSD to
> use Guix-for-2.2, running ‘guix’ typically gives loads of warnings like:
>
>   ;;; WARNING: loading compiled file /home/ludo/.config/guix/latest/guix/derivations.go failed:
>   ;;; ERROR: In procedure load-thunk-from-memory: No such file or directory

With commit 838ba73d6e49bd2b1f2d4ed9329b65cc4e8c1f54, ‘guix pull’ builds
with the currently used Guile, be it 2.0 or 2.2.  To achieve that, it
tries hard to pick 2.0 or 2.2 packages for the dependencies of Guix.

If it cannot find a “guile-ssh” package for the Guile being used (for
instance, you’re using Guile 2.2 but lacking the “guile-ssh” package
built with 2.2), then it simply skips modules that depend on Guile-SSH;
they are optional anyway.  For Guile-JSON, it just assumes that there is
a matching Guile-JSON, which should be the case anyway.

As I wrote before, ‘guix pull’ in its current form is pretty fragile;
please report any problems you have.


In addition, with commit 7561881f2a5d2dc463c24713745eca03e67044bf, the
“guix” package is now built with Guile 2.2 instead of 2.0.  Thus, next
time you update GuixSD, /run/current-system/profile/bin/guix will be
using Guile 2.2.  At that point, if ~/.config/guix/latest contains .go
files for 2.0, you’ll get warnings as shown above, and you’ll have to
“guix pull” to get rid of them.


At this point, we’re still using Guile 2.0 (1) to build derivations, and
(2) in the Shepherd, mcron, and modules imported inside the Shepherd.
In ‘core-updates’ we have addressed #1 and we’ll address #2 as well.

Ludo’.

Re: Heads-up: transition to Guile 2.2

[Pjotr Prins]

On Tue, May 09, 2017 at 11:22:05PM +0200, Ludovic Court??s wrote:
> Hello Guix!
> 
> ludo@gnu.org (Ludovic Court??s) skribis:
> 
> > There???s a problem though, called ???guix pull???.  ~/.config/guix/latest
> > currently contains 2.0 .go files.  Thus after reconfiguring GuixSD to
> > use Guix-for-2.2, running ???guix??? typically gives loads of warnings like:
> >
> >   ;;; WARNING: loading compiled file /home/ludo/.config/guix/latest/guix/derivations.go failed:
> >   ;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
> 
> With commit 838ba73d6e49bd2b1f2d4ed9329b65cc4e8c1f54, ???guix pull??? builds
> with the currently used Guile, be it 2.0 or 2.2.  To achieve that, it
> tries hard to pick 2.0 or 2.2 packages for the dependencies of Guix.

I have just wasted a few hours trying to find a way to
bootstrap the latest tree. And I got it to work haphazardly - that
means I can't reproduce what I did.

Starting from running 'guix pull' twice and essentially following the section
'Building GNU Guix from source (using Guix)' in

  https://gitlab.com/pjotrp/guix-notes/blob/master/INSTALL.org#building-gnu-guix-from-source-using-guix

which used to work reliably. It all has to do with the guile upgrade. Even from
a clean git clone it won't work as expected.

Typical errors during build are

  Backtrace:
    GUILEC   gnu/packages/fcitx.go
  Exception thrown while printing backtrace:
    GUILEC   ERROR: gnu/packages/figlet.go
    In procedure public-lookup: Module named (system repl debug) does
    not exist

But I got it somehow to build. guix now lacks a version number:

  ./pre-inst-env guix --version
  guile: warning: failed to install locale
    warning: failed to install locale: Invalid argument
    guix (GNU Guix) UNKNOWN

probably because bootstrap never did the right thing. Bootstrap passes, but 

  ./configure --localstatedir=/var

complains with 

  configure: error: C preprocessor "/lib/cpp" fails sanity check

And during installation:

  ERROR: In procedure stat:
  ERROR: In procedure stat: No such file or directory:
  "/gnu/store/q5kdj7gpawi94pqd15x3wizjq0nx4zhx-python-2.7.13/share/man/man1/python.1"

(I remember that one from earlier days, it is a missing symlink)

In all, the system feels flaky at this point. I wish we had found a
way of upgrading guile with backward compatibility. Maybe temporarily
naming it guile2.2 with matching paths would have been better.

Pj.

Re: Heads-up: transition to Guile 2.2

[Pjotr Prins]

I rolled back all the way to March to get a reproducable stable
system again. 

At least we can do that, unlike almost any other software distribution
:). 

We'll be on guile 2.0 for the time being until we can get a reliable
upgrade path. Maybe it is the combination with the major gcc update to
7.10 that makes things unstable. I could not figure it out, just see
the result.

Pj.

Re: Heads-up: transition to Guile 2.2

[Pjotr Prins]

I rolled back all the way to March to get a reproducable stable
system again. 

At least we can do that, unlike almost any other software distribution
:). 

We'll be on guile 2.0 for the time being until we can get a reliable
upgrade path. Maybe it is the combination with the major gcc update to
7.10 that makes things unstable. I could not figure it out, just see
the result.

Pj.



-- 

Re: Heads-up: transition to Guile 2.2

[Jan Nieuwenhuizen]

Pjotr Prins writes:

> I rolled back all the way to March to get a reproducable stable
> system again. 

Ugh...I'm not sure what troubles you encountered.  I have been using
guile-2.2 for two years now; and have been "fighting" Guix's use of
guile-2.0...

Most troublesome is that some packages set GUILE_LOAD_PATH and
GUILE_LOAD_COMPILED_PATH and mixing guile-2.0 and guile-2.2 packages
that do so is still troublesome.  It would be nice (TM) if we could
find a way not to rely on setting those environment variables.

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: Heads-up: transition to Guile 2.2

[pjotr.public12]

On Sun, May 14, 2017 at 06:28:01PM +0200, Jan Nieuwenhuizen wrote:
> Most troublesome is that some packages set GUILE_LOAD_PATH and
> GUILE_LOAD_COMPILED_PATH and mixing guile-2.0 and guile-2.2 packages
> that do so is still troublesome.  It would be nice (TM) if we could
> find a way not to rely on setting those environment variables.

One thing I noticed was that gnutls was in the 2.2 path and json was
in 2.0. Providing both paths did help compilation. It was one thing I
did. But it does not feel quite right :)

It appears to me that we shoud have a reproducable bootstrap path at
every stage of the tree. I mean for building from the checked out git
tree of guix.

Pj.

Creating a reliable bootstrap for building from source

[Pjotr Prins]

Thinking about it, what I want to achieve is that we can take the
latest git tree and bootstrap by building guix and packages. This
should be easy, since I have guix running, but it is not. And the main
trouble is that the underlying build packages can differ over time. I
am looking at gcc versions and guile versions.  I.e., we are building
on shifting sands. How unguixy!

The combination of 'guix pull' held a promise, were it not that pull is
also iffy. Probably for pretty much the same reason.

The bootstrap+configure scripts try to work that, but actually
address a wider case. I.e. people who want to bootstrap in Debian etc.
I don't think we need al that. I write Makefile.guix for my projects
and they tend to be simple! Once you can assume Guix is there life
gets simple as a developer - except when you try to bootstrap :0

The instruction I would like to write for others is:

1. Install the latest bootstrap-guix-from-source package after a guix pull
2. git clone guix && cd guix
3. run make -f Makefile.guix  

(no configure is needed in guix!)

4. ./pre-inst guix etc. etc.

Now the bootstrap-guix-from-source package is easy to create and needs
one single test: build guix from the git tree. It should have a
dependency on the git tree itself, so it gets forced every time on the
build farm.

Once we have that we can even bootstrap using guix pack and such.

I realise potluck could be an alternative, but a working bootstrap
would make guix pull also reliable and we can test it effectively on
the build farm.

Pj. 

(unguixy, I like that. It applies to many deployment statements. The
world is an unguixy place)

Re: Creating a reliable bootstrap for building from source

[Ludovic Courtès]

Pjotr Prins <pjotr.public12@thebird.nl> skribis:

> The combination of 'guix pull' held a promise, were it not that pull is
> also iffy. Probably for pretty much the same reason.
>
> The bootstrap+configure scripts try to work that, but actually
> address a wider case. I.e. people who want to bootstrap in Debian etc.
> I don't think we need al that. I write Makefile.guix for my projects
> and they tend to be simple! Once you can assume Guix is there life
> gets simple as a developer - except when you try to bootstrap :0
>
> The instruction I would like to write for others is:
>
> 1. Install the latest bootstrap-guix-from-source package after a guix pull
> 2. git clone guix && cd guix
> 3. run make -f Makefile.guix  
>
> (no configure is needed in guix!)
>
> 4. ./pre-inst guix etc. etc.

I think there are two very different use cases.

As a user I want something like ‘apt-get update’, which is what ‘guix
pull’ tries to do.

For Guix developers, I think it’s reasonable to have a traditional GNU
build system.  After all, Guix is also a regular software package that
people can build from source with “./configure && make && make install”.

My 2¢,
Ludo’.

Re: Creating a reliable bootstrap for building from source

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 1080 bytes --]

Heya,

> As a user I want something like ‘apt-get update’, which is what ‘guix
> pull’ tries to do.

For end-users, cool stuff would be:

	nguix	[ guix-ncurse

		u	[ update the aptitude cached list of all packages,
			[ installed or not... just package descriptions, nothing
			[ has been downloaded yet
		U	[ mark as 'wish to update'
		g	[ list the above marked for update packages, then fine tune
			[ using =, -, + ...
		g	ok, download what I really selected to be updated
			and update...

		note that the most important aptitude ncurse menu is 'Cancel pending
		actions' :)

	or using emacs, 'à la magit'

	M-x guix-status
		u
		U
		...

> For Guix developers, I think it’s reasonable to have a traditional GNU
> build system.  After all, Guix is also a regular software package that
> people can build from source with “./configure && make && make install”.

If I could just grab guile-gnutls and  “./configure && make && make install”
then I could compile, play, use, learn, contribute with/to guix...

Cheers,
David

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Creating a reliable bootstrap for building from source

[Ludovic Courtès]

Hi David,

David Pirotte <david@altosw.be> skribis:

>> As a user I want something like ‘apt-get update’, which is what ‘guix
>> pull’ tries to do.
>
> For end-users, cool stuff would be:
>
> 	nguix	[ guix-ncurse
>
> 		u	[ update the aptitude cached list of all packages,
> 			[ installed or not... just package descriptions, nothing
> 			[ has been downloaded yet
> 		U	[ mark as 'wish to update'
> 		g	[ list the above marked for update packages, then fine tune
> 			[ using =, -, + ...
> 		g	ok, download what I really selected to be updated
> 			and update...
>
> 		note that the most important aptitude ncurse menu is 'Cancel pending
> 		actions' :)
>
> 	or using emacs, 'à la magit'
>
> 	M-x guix-status
> 		u
> 		U
> 		...

How would that differ from what Emacs-Guix provides?

>> For Guix developers, I think it’s reasonable to have a traditional GNU
>> build system.  After all, Guix is also a regular software package that
>> people can build from source with “./configure && make && make install”.
>
> If I could just grab guile-gnutls and  “./configure && make && make install”
> then I could compile, play, use, learn, contribute with/to guix...

David, if your distro does not provide a guile-gnutls package, you can
always install Guix via the binary installation method:

  https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html

HTH!

Ludo’.

Re: Creating a reliable bootstrap for building from source

[Pjotr Prins]

On Sun, May 14, 2017 at 11:32:06PM +0200, Ludovic Court??s wrote:
> Pjotr Prins <pjotr.public12@thebird.nl> skribis:
> 
> > The combination of 'guix pull' held a promise, were it not that pull is
> > also iffy. Probably for pretty much the same reason.
> >
> > The bootstrap+configure scripts try to work that, but actually
> > address a wider case. I.e. people who want to bootstrap in Debian etc.
> > I don't think we need al that. I write Makefile.guix for my projects
> > and they tend to be simple! Once you can assume Guix is there life
> > gets simple as a developer - except when you try to bootstrap :0
> >
> > The instruction I would like to write for others is:
> >
> > 1. Install the latest bootstrap-guix-from-source package after a guix pull
> > 2. git clone guix && cd guix
> > 3. run make -f Makefile.guix  
> >
> > (no configure is needed in guix!)
> >
> > 4. ./pre-inst guix etc. etc.
> 
> I think there are two very different use cases.
> 
> As a user I want something like 'apt-get update', which is what 'guix
> pull' tries to do.

Sure. But from my previous E-mail you can see we are effectively using
pull to bootstrap the source tree build.

> For Guix developers, I think it's reasonable to have a traditional GNU
> build system.  After all, Guix is also a regular software package that
> people can build from source with './configure && make && make install'.

My point is that we can simplify. I like simple. Simple is good.

We can have both the configure and a simple Makefile.guix option. That
is what I do with my projects.

We do not need bootstrap, autoconf and configure on a running Guix
system. We do need it for other distributions.

Anyway, feel free to ignore this idea.

Pj.
-- 

Re: Creating a reliable bootstrap for building from source

[Ludovic Courtès]

Pjotr Prins <pjotr.public12@thebird.nl> skribis:

> On Sun, May 14, 2017 at 11:32:06PM +0200, Ludovic Court??s wrote:
>> Pjotr Prins <pjotr.public12@thebird.nl> skribis:
>> 
>> > The combination of 'guix pull' held a promise, were it not that pull is
>> > also iffy. Probably for pretty much the same reason.
>> >
>> > The bootstrap+configure scripts try to work that, but actually
>> > address a wider case. I.e. people who want to bootstrap in Debian etc.
>> > I don't think we need al that. I write Makefile.guix for my projects
>> > and they tend to be simple! Once you can assume Guix is there life
>> > gets simple as a developer - except when you try to bootstrap :0
>> >
>> > The instruction I would like to write for others is:
>> >
>> > 1. Install the latest bootstrap-guix-from-source package after a guix pull
>> > 2. git clone guix && cd guix
>> > 3. run make -f Makefile.guix  
>> >
>> > (no configure is needed in guix!)
>> >
>> > 4. ./pre-inst guix etc. etc.
>> 
>> I think there are two very different use cases.
>> 
>> As a user I want something like 'apt-get update', which is what 'guix
>> pull' tries to do.
>
> Sure. But from my previous E-mail you can see we are effectively using
> pull to bootstrap the source tree build.

Sure.

>> For Guix developers, I think it's reasonable to have a traditional GNU
>> build system.  After all, Guix is also a regular software package that
>> people can build from source with './configure && make && make install'.
>
> My point is that we can simplify. I like simple. Simple is good.
>
> We can have both the configure and a simple Makefile.guix option. That
> is what I do with my projects.
>
> We do not need bootstrap, autoconf and configure on a running Guix
> system. We do need it for other distributions.

I agree.  build-aux/build-self.scm, which is what ‘guix pull’ runs to
build Guix, is close to what you’re suggesting, IIUC: a pure-Guile build
script.  WDYT?

Ludo’.

Re: Creating a reliable bootstrap for building from source

[Pjotr Prins]

On Mon, May 15, 2017 at 03:28:58PM +0200, Ludovic Court??s wrote:
> >> For Guix developers, I think it's reasonable to have a traditional GNU
> >> build system.  After all, Guix is also a regular software package that
> >> people can build from source with './configure && make && make install'.
> >
> > My point is that we can simplify. I like simple. Simple is good.
> >
> > We can have both the configure and a simple Makefile.guix option. That
> > is what I do with my projects.
> >
> > We do not need bootstrap, autoconf and configure on a running Guix
> > system. We do need it for other distributions.
> 
> I agree.  build-aux/build-self.scm, which is what ???guix pull??? runs to
> build Guix, is close to what you???re suggesting, IIUC: a pure-Guile build
> script.  WDYT?

It is interesting - especially the hoops jumping around guile
versioning ;) - but it still looks like it invokes the traditional
gnu-build-system. I think we can do without that too. 

Pj.
-- 

Re: Creating a reliable bootstrap for building from source

[Ludovic Courtès]

Pjotr Prins <pjotr.public12@thebird.nl> skribis:

> On Mon, May 15, 2017 at 03:28:58PM +0200, Ludovic Court??s wrote:
>> >> For Guix developers, I think it's reasonable to have a traditional GNU
>> >> build system.  After all, Guix is also a regular software package that
>> >> people can build from source with './configure && make && make install'.
>> >
>> > My point is that we can simplify. I like simple. Simple is good.
>> >
>> > We can have both the configure and a simple Makefile.guix option. That
>> > is what I do with my projects.
>> >
>> > We do not need bootstrap, autoconf and configure on a running Guix
>> > system. We do need it for other distributions.
>> 
>> I agree.  build-aux/build-self.scm, which is what ???guix pull??? runs to
>> build Guix, is close to what you???re suggesting, IIUC: a pure-Guile build
>> script.  WDYT?
>
> It is interesting - especially the hoops jumping around guile
> versioning ;) - but it still looks like it invokes the traditional
> gnu-build-system.

No, (guix scripts pull) really just traverses the list of .scm files and
compiles them.

Ludo’.

Re: Creating a reliable bootstrap for building from source

[Pjotr Prins]

On Sun, May 14, 2017 at 11:32:06PM +0200, Ludovic Court??s wrote:
> For Guix developers, I think it???s reasonable to have a traditional GNU
> build system.  After all, Guix is also a regular software package that
> people can build from source with ???./configure && make && make install???.

This is the procedure I have now for creating a reliable bootstrap
from source:

The safest route is by using guix environment after starting
a clean shell

  screen -S guix-build # I tend to build in screen
  env -i /bin/bash --login --noprofile --norc
  ~/.guix-profile/bin/guix environment guix --ad-hoc help2man git strace \
    pkg-config less vim binutils coreutils grep --no-grafts
  bash # you may want this shell

In fact pick the most recent guix you have got, see 'ls
/gnu/store/*guix*/bin/guix' and run that command. Use the --no-grafts
switch if you have built packages that way before.

Note that you can start guix by installing the binary tar ball, or
copying it from another machine using the rather useful guix archive
or [[https://www.gnu.org/software/guix/news/creating-bundles-with-guix-pack.html][guix pack]] commands.

You may want to take a note of these running versions

  gcc --version
  guile --version

Next in the source tree

  rm -rf autom4te.cache/ # to be sure
  make clean
  ./bootstrap
  ./configure --localstatedir=/var
  make clean # to be really sure
  time make

It works reliably on all my setups :). Note that typically gcc is v4 or v5 and guile 2.0.x,
but never the same.

I am pleased with this until it stops working ... I think it should go in the manual and
we should have an automated test on this procedure.

Pj.
--