Re: 01/02: build: gnu-build-system: Don't run configure during bootstrap.

[Bengt Richter <bokr@bokr.com>]

Hi Marius,

On +2020-02-16 17:34:13 +0100, Marius Bakke wrote:
> Bengt Richter <bokr@bokr.com> writes:
> 
> > Hi Efraim,
> >
> > On +2020-02-16 16:55:17 +0200, Efraim Flashner wrote:
> >> On Sun, Feb 16, 2020 at 03:27:36PM +0100, Marius Bakke wrote:
> >> > guix-commits@gnu.org writes:
> >> > 
> >> > > commit 481a0f1a7ceac666a011b28324220584ead07698
> >> > > Author: Efraim Flashner <efraim@flashner.co.il>
> >> > > AuthorDate: Thu Feb 13 10:54:29 2020 +0200
> >> > >
> >> > >     build: gnu-build-system: Don't run configure during bootstrap.
> >> > >     
> >> > >     * guix/build/gnu-build-system.scm (bootstrap): Add NOCONFIGURE
> >> > >     environment variable before running bootstrap scripts.
> >> > 
> >> > [...]
> >> > 
> >> > > @@ -190,6 +190,7 @@ working directory."
> >> > >                (if (executable-file? script)
> >> > >                    (begin
> >> > >                      (patch-shebang script)
> >> > > +                    (setenv "NOCONFIGURE" "true")
> >> > >                      (invoke script))
> >> > >                    (invoke "sh" script)))
> >> > >              (if (or (file-exists? "configure.ac")
> >> > 
> >> > Should we unset NOCONFIGURE afterwards?  Probably at least one package
> >> > uses this variable for something completely different...
> >> 
> >> It probably wouldn't hurt to unset it. I've never come across a package
> >> where that's been a problem but best not invite trouble.
> >>
> > With all due respect, I am not comfortable with this kind of rationale :) 
> >
> > If it's never been a problem, unsetting might hide a case where it _would_
> > cause a problem -- which IMO it would be better to find out about than not.
> 
> I'm not sure I follow.  The variable in question has only been used in a
> handful of packages[0].  Now we are adding it in nearly 10k packages.
>
Yow, I sure didn't mean to suggest that!
 
> Why would we want to know whether a package build process has a problem
> with that particular variable?
Debugging unexpected results?

I was reacting to
┌───────────────────────────────────────────────────────────────────────────────┐
│ > >> > Should we unset NOCONFIGURE afterwards?  Probably at least one package │
│ > >> > uses this variable for something completely different...               │
│ > >>                                                                          │
│ > >> It probably wouldn't hurt to unset it. I've never come across a package  │
│ > >> where that's been a problem but best not invite trouble.                 │
└───────────────────────────────────────────────────────────────────────────────┘
and wondering what kind of problem was anticipated if NOCONFIGURE were left set.

So I thought, if you unset it, you will never discover that problem.
Then I doubled down with the rest, to suggest forcing the ghost problem
to show itself ;-)

My motivation was to make any problem more easily debuggable rather than less,
but it was about debugging, not standard operating procedure.

> 
> [0] https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates&id=778d6b522ae361767d3cf984a3b182bac7361b7a

-- 
Regards,
Bengt Richter