From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id GP7OFckeUWBDfQAA0tVLHw (envelope-from ) for ; Tue, 16 Mar 2021 21:10:33 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id eMiZEckeUWClcgAA1q6Kng (envelope-from ) for ; Tue, 16 Mar 2021 21:10:33 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id DDDC615B1A for ; Tue, 16 Mar 2021 22:10:32 +0100 (CET) Received: from localhost ([::1]:60448 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lMGxU-0003Bz-08 for larch@yhetil.org; Tue, 16 Mar 2021 17:10:32 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50230) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lMGx0-00036L-6V for guix-patches@gnu.org; Tue, 16 Mar 2021 17:10:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:57866) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lMGwz-0000mw-Tq for guix-patches@gnu.org; Tue, 16 Mar 2021 17:10:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lMGwz-0003gn-OZ for guix-patches@gnu.org; Tue, 16 Mar 2021 17:10:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#47153] [PATCH v2] gnu: chez-scheme: Update nanopass to 1.9.2. Resent-From: Leo Prikler Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Tue, 16 Mar 2021 21:10:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47153 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Philip McGrath , 47153@debbugs.gnu.org Received: via spool by 47153-submit@debbugs.gnu.org id=B47153.161592899014149 (code B ref 47153); Tue, 16 Mar 2021 21:10:01 +0000 Received: (at 47153) by debbugs.gnu.org; 16 Mar 2021 21:09:50 +0000 Received: from localhost ([127.0.0.1]:41174 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lMGwn-0003g8-Re for submit@debbugs.gnu.org; Tue, 16 Mar 2021 17:09:50 -0400 Received: from mailrelay.tugraz.at ([129.27.2.202]:47351) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lMGwj-0003fr-IE for 47153@debbugs.gnu.org; Tue, 16 Mar 2021 17:09:48 -0400 Received: from nijino.local (217-149-164-20.nat.highway.telekom.at [217.149.164.20]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4F0QsK2Y7lz1DDYw; Tue, 16 Mar 2021 22:09:41 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4F0QsK2Y7lz1DDYw DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1615928981; bh=ddNI2QhcSDlSirUpO/VCv3nP8tvNnoi3bFt3z4FcFC0=; h=Subject:From:To:Date:In-Reply-To:References:From; b=K3K8BIAjvFvmR9T2g0+yDBEeL+j3EZGU1VdXmsEQs/GCJUNQQbHWikAfj9snzfmZ2 zPxWSwvqis2Opgc3yemE51Q+WnKoOC60gRZCVtxLXM4f8rwhMpqWSQPOZHKae1vqoD uoJVMi25dLybw23l9q9yoLTo6Ad3opixFyfqv5V8= Message-ID: <5c833412d1ef4c9130c7f769a7d2c6d4270d7d36.camel@student.tugraz.at> From: Leo Prikler Date: Tue, 16 Mar 2021 22:09:40 +0100 In-Reply-To: <5a4d612f-445a-e3f0-a3ff-7abd4b021f16@philipmcgrath.com> References: <9581850ed011d311db0388fcda41f8fbcd479730.camel@student.tugraz.at> <20210315225302.6597-1-philip@philipmcgrath.com> <6e49888aaab2d2b2284d198eca51d0b9944be613.camel@student.tugraz.at> <5a4d612f-445a-e3f0-a3ff-7abd4b021f16@philipmcgrath.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TUG-Backscatter-control: bt4lQm5Tva3SBgCuw0EnZw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1615929033; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=ddNI2QhcSDlSirUpO/VCv3nP8tvNnoi3bFt3z4FcFC0=; b=NqYD+khnGBcFrBRyFwXfr51fZa8/97vyiz6tfjLcyKEsDxveYQEBfKfA51SlA9HFbBTl/9 IxpF/Ju8qTndCuMKMudAmuXaf+iXt+tG2SQLmamuAw2FgIwU3gyajegYWGzQMABRydt8NE g6wkg7aHmn7JUOXM+my04hfPpXqsvXwWmwTG+R09P0xl2pC0tuxz693x2RGcIIMyU1c51l Mw75BhOxUMuhZdADhy68f6Flk9mGlS/imkwnc2BWn9/Mzll/lJpbUt8bJ46hFCjNUleYCo M2J2s0wqvKJOBEchyEmtYqzzd2NIB196X3JxYNYN66J9n1Ld6SwYOy41iCYt8w== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1615929033; a=rsa-sha256; cv=none; b=kZIW9kzSIl7yoQzzC6l1EXOqFskOUXJKBo/mveEeBQv93oXjrtsi/CtU+t4VRtyC0jUs50 1IdPUVL7MR/Zjm5aM1bc+3+o7Og7SF77GehG0u4lhiaQ58lxxNZ+abww1UdLgmyPkw6qp0 KS9lUxmgRbaH04R+lEJnkfwDCGfHwxv8Vh+9ds644li/QYh1HLtqBWFLRycmMkwRX7DlF1 NDAwT9lz1pqAnslQi2o87BrUowaL1KfpNR0sxSVgrYvUYg85V4Jss3jkOMrT5GfN9hWjSV 7unxx+7Cksr5IT2JYzDit8wmSogYEnaEAXHOsgP72FiZImMZ8PjM1EAn0grNmA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tugraz.at header.s=mailrelay header.b=K3K8BIAj; spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Migadu-Spam-Score: -1.30 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tugraz.at header.s=mailrelay header.b=K3K8BIAj; dmarc=fail reason="SPF not aligned (relaxed)" header.from=student.tugraz.at (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Migadu-Queue-Id: DDDC615B1A X-Spam-Score: -1.30 X-Migadu-Scanner: scn0.migadu.com X-TUID: Jy4uW9J0bgvd Hi, Am Dienstag, den 16.03.2021, 16:19 -0400 schrieb Philip McGrath: > Hi, > > On 3/16/21 3:37 AM, Leo Prikler wrote: > > Am Montag, den 15.03.2021, 18:53 -0400 schrieb Philip McGrath: > > > - (sha256 (base32 > > > "1synadgaycca39jfx525975ss9y0lkl516sdrc62wrrllamm8n21")) > > > + (sha256 > > > "16vjsik9rrzbabbhbxbaha51ppi3f9n8rk59pc6zdyffs0vziy4i") > > You're inadvertently stripping away base32. > > I thought I'd read that explicitly calling base32 was redundant and > no > longer recommended: is there a reason to keep it? Without a reference to where you've read that, it'll be hard to verify or falsify that claim. Both master and core-updates regularly see sha256/base32 is fancy syntax around hash-digest and hash-algo as far as I understand, so I doubt you recall this correctly. > > > - (commit (string-append "v" version)))) > > > + ;; This commit includes a fix for which we would > > > + ;; otherwise want to use a snippet. > > > + ;; When there's a new tagged release, > > > + ;; go back to using (string-append "v" version) > > > + (commit > > > "54051494434a197772bf6ca5b4e6cf6be55f39a5"))) > > Could we then not cherry-pick this commit as a patch? Or is there > > more > > needed? > > We could, but the upstream history is simply v1.2.2 -> my patch -> > Kent > Dybvig's merge commit accepting it. I thought doing it this way > clarified that it's not a Guix-specific patch that should stay > around > indefinitely. Is there a reason to prefer cherry-picking it as a > patch? You'll probably hear differing opinions about that, and that's fine, but my personal reason to prefer cherry-picking would be, that it makes it very obvious, what changed from the base – that being the patch modulo offset changes – and doesn't invite people to go out saying "aha, but I found this commit and I like that more, let's take it". In other words, this is very subjective, but I believe we should stick as close to releases as is reasonable. > > > + ;; pre-built bootfiles for unsupported > > > systems: > > > + "boot/a6nt" > > > + "boot/a6osx" > > > + "boot/i3nt" > > > + "boot/i3osx" > > > + "boot/ta6nt" > > > + "boot/ta6osx" > > > + "boot/ti3nt" > > > + "boot/ti3osx"))))))) > > What about pre-built bootfiles for supported systems? Do we still > > need > > those? If we so, I don't think it is right to delete anything in > > boot; > > if not we should delete it altogether. > > Currently, you need a bootfile for your current system to bootstrap > the > Chez compiler; once you have a running Chez, you can build bootfiles > for > any system Chez supports (which is more systems than it includes in > its > git repository for bootstrapping). The bootfiles you build will be > byte-for-byte identical to pre-built ones, if pre-built ones were > provided: Chez in fact builds them twice and errors if they aren't. > So, > I'm not sure why we would want these files, which are over 20 MB and > are > only useful for bootstrapping Chez on Windows or Mac OS. But if there > is > a reason to want them, we can keep them! I don't think we can necessarily trust the boot files in this configuration. "They are bit-for-bit identical" can also mean, that the login() hack was successfully applied for all you know. But trusting trust aside, I don't think this is the right way of "miraculously slashing" half of chez' bootstrap. If you do want to follow the direction of making the bootstrap explicit, how about a chez-boot minipackage, that only keeps the relevant boot files for the target system? (This would of course need to be done in a separate patch, which you can attach to this series, however.) > > > + (apply invoke > > > + "./configure" > > > + flags) > > This can very likely be one line. Also, it should probably be done > > via > > configure-flags. > > > > > [outputs]: Add "stex" > > I don't think an stex output is justified in and of itself, or is > > it > > Oops, I'd actually removed the "stex" output, but I missed it in the > commit message. I do think I saw it in the actual commit as well, but I might be mistaken about that. > > > + (flags (if (assoc-ref inputs "ncurses") > > > + flags > > > + (cons "--disable-curses" > > > + flags))) > > > + (flags (if (assoc-ref inputs "libx11") > > > + flags > > > + (cons "--disable-x11" > > > + flags)))) > > These will probably be detected by the build system itself, there's > > no > > need for you to add them. If not, then it's up to the packager of > > other variants to specify them, not you. > > IIRC, Chez's build system errors without these flags if the library > isn't found. Also, I intend to be "the packager of the other > variants"—my primary motivation for sending these patches is to reuse > as > much as possible for Racket's fork of Chez, rather than all of the > messy > copy-pasting we're doing now. But see below … Fair enough, but either way you should just cons them onto #:configure- flags where applicable. > > > + (flags (list > > > + (string-append "--installprefix=" > > > out) > > > + (string-append "ZLIB=" zlib-static > > > "/lib/libz.a") > > > + (string-append "LZ4=" lz4-static > > > "/lib/liblz4.a") > > > + "--nogzip-man-pages" ;; guix will do > > > it > > > + "--threads")) > > This should be done via #:configure-flags. > > > > Now that I think of it… > > > > > + (replace 'configure > > I don't think this is needed at all. At most, you should filter > > the > > incompatible flags from configure-flags in some way, but you might > > also > > want to patch configure, so that it swallows them. > > I'm not enthusiastic about the idea of maintaining such a patch for > two > variants of this custom configure script which accept different sets > of > flags, but neither of which accepts *any* of the flags that would be > added by the 'configure phase from %standard-phases. That procedure > offers no way to interpose between its adding the flags and its > invoking > the configure script, so I don't see a good alternative to replacing > it. > In fact, I'd modeled my implementation on the one from %standard- > phases, > which similarly has a big `let*` expression adding implicit phases > based > on the inputs and outputs. > > If you think it's important to support #:configure-flags, I could > change > this implementation to accept them, in which case I'd be ok with > leaving > out handling of --disable-curses and --disable-x11. But I think > anyone > packaging a variant of Chez will need to be aware of its > idiosyncratic > configure script. Perhaps I was a little too harsh. If you need to replace 'configure to not let gnu-build-system's own flags pass into this idiosyncratic script, you are of course allowed to do that. I just think storing configure flags inside the argument that's named like that is a better choice, than an ad-hoc construction. Whatever you see inside that standard-phase is done precisely because storing it as an argument would not be an option. > > > Refactor 'install-doc' phase into 'build+install-stex' and > > > 'build+install-doc' > > 'build+install' implies, that it should actually be two phases, > > build > > and install. I already talked about install-stex, so you should > > only > > refactor install-doc insofar as it is needed to accommodate changes > > in > > the build system. > > It could be two phases, but the current install-doc phase does, in > fact, > also build the docs, in addition to installing them. (It actually > neglects to install the HTML release notes but installs two copies > of > the PDF user's guide.) I'm ok with calling it install-doc if you > prefer. > I guess I could even split it into two phases, but that seems like > it > would just make things more complicated for no obvious benefit. That is irrelevant, `make install' is not prohibited from building stuff. > As I mentioned, build+install-stex actually just "installs" stex to > a > temporary directory right now. I think I could probably skip it and > rely > on Chez's on-the-fly compilation, but I didn't see a problem with > doing > it this way. Sounds like it might work. Regards, Leo