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

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

[Marius Bakke]

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

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...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Efraim Flashner]

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

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.

Also, looking at the snippet, I should move it higher up. If it's not
executable then NOCONFIGURE doesn't get set.


-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Bengt Richter]

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.

Is there an official policy regarding garbage/dangling environment variables?

(Or is that just to be expected in the sargasso sea of "undefined behaviour"? ;-)

So, if in doubt, instead of unsetting, perhaps set it something like

    "IF_YOU_SEE_THIS_PLEASE_REPORT_HOW_IT_HAPPENED_TO_efraim_AT_flashner.co.il"

;-P

or make it throw an exception somehow, if following processing uses NOCONFIGURE
any way at all before being replaced with a proper meaningful new value.

> Also, looking at the snippet, I should move it higher up. If it's not
> executable then NOCONFIGURE doesn't get set.
> 
> 
> -- 
> Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted

Hope I didn't offend anyone :)
-- 
Regards,
Bengt Richter

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

[Marius Bakke]

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

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.

Why would we want to know whether a package build process has a problem
with that particular variable?

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Bengt Richter]

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

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

[Marius Bakke]

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

Bengt Richter <bokr@bokr.com> writes:

>> Why would we want to know whether a package build process has a problem
>> with that particular variable?
> Debugging unexpected results?

As fun as that is, I think we have enough things to debug already!  :-)

> 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 ;-)

Right.  While I generally agree with the sentiment, in this case, by the
time we discovered any problem it would be too late to fix!  Because
changing gnu-build-system entails a full rebuild we have to be extra
careful with what goes on in there.

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

To me it's also about purity: the purpose of NOCONFIGURE is to work
around some corner cases with the typical "bootstrap" scripts found in
Autotools projects.  Thus it is really not useful outside of the
'bootstrap' phase, unlike say PATH, which is also set by
gnu-build-system.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Efraim Flashner]

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

On Sun, Feb 16, 2020 at 05:24:22PM +0100, Bengt Richter wrote:
> 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.
> 
> Is there an official policy regarding garbage/dangling environment variables?
> 
> (Or is that just to be expected in the sargasso sea of "undefined behaviour"? ;-)
> 
> So, if in doubt, instead of unsetting, perhaps set it something like
> 
>     "IF_YOU_SEE_THIS_PLEASE_REPORT_HOW_IT_HAPPENED_TO_efraim_AT_flashner.co.il"
> 
> ;-P
> 
> or make it throw an exception somehow, if following processing uses NOCONFIGURE
> any way at all before being replaced with a proper meaningful new value.
> 
> > Also, looking at the snippet, I should move it higher up. If it's not
> > executable then NOCONFIGURE doesn't get set.
> > 
> 
> Hope I didn't offend anyone :)

(ins)efraim@E5400 ~$ env | grep -i pants
PANTS=ON

There's some inside joke somewhere in Enlightenment that I don't know.
I've found the code that sets PANTS=ON but I've never tried changing it.

The beginning of the gnu-build-system goes:
(phases set-SOURCE-DATE-EPOCH set-paths install-locale unpack
        bootstrap

So if NOCONFIGURE is set previously it's from us anyway. So in this case
I think it's fair to clean up after ourselves.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]