From: Marius Bakke <mbakke@fastmail.com>
To: Bengt Richter <bokr@bokr.com>
Cc: guix-devel@gnu.org
Subject: Re: 01/02: build: gnu-build-system: Don't run configure during bootstrap.
Date: Tue, 18 Feb 2020 18:38:20 +0100 [thread overview]
Message-ID: <87a75f6bjn.fsf@devup.no> (raw)
In-Reply-To: <20200216171837.GA6663@LionPure>
[-- 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 --]
next prev parent reply other threads:[~2020-02-18 17:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200216072616.4957.58376@vcs0.savannah.gnu.org>
[not found] ` <20200216072618.88AB021120@vcs0.savannah.gnu.org>
2020-02-16 14:27 ` 01/02: build: gnu-build-system: Don't run configure during bootstrap Marius Bakke
2020-02-16 14:55 ` Efraim Flashner
2020-02-16 16:24 ` Bengt Richter
2020-02-16 16:34 ` Marius Bakke
2020-02-16 17:18 ` Bengt Richter
2020-02-18 17:38 ` Marius Bakke [this message]
2020-02-16 16:48 ` Efraim Flashner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a75f6bjn.fsf@devup.no \
--to=mbakke@fastmail.com \
--cc=bokr@bokr.com \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).