[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 01/02: build: gnu-build-system: Don't run configure during bootstrap
From: |
Bengt Richter |
Subject: |
Re: 01/02: build: gnu-build-system: Don't run configure during bootstrap. |
Date: |
Sun, 16 Feb 2020 18:18:37 +0100 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
Hi Marius,
On +2020-02-16 17:34:13 +0100, Marius Bakke wrote:
> Bengt Richter <address@hidden> 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:
> >> > address@hidden writes:
> >> >
> >> > > commit 481a0f1a7ceac666a011b28324220584ead07698
> >> > > Author: Efraim Flashner <address@hidden>
> >> > > 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