From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 8MZlLo0UUWBkKwAA0tVLHw (envelope-from ) for ; Tue, 16 Mar 2021 20:26:53 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id cBlRKo0UUWDQVwAA1q6Kng (envelope-from ) for ; Tue, 16 Mar 2021 20:26:53 +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 4C10121F87 for ; Tue, 16 Mar 2021 21:26:53 +0100 (CET) Received: from localhost ([::1]:48320 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lMGHE-0000qw-5l for larch@yhetil.org; Tue, 16 Mar 2021 16:26:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36722) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lMGAc-0003fd-8V for guix-patches@gnu.org; Tue, 16 Mar 2021 16:20:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:57818) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lMGAb-00021m-WB for guix-patches@gnu.org; Tue, 16 Mar 2021 16:20:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lMGAb-0002Ud-Qs for guix-patches@gnu.org; Tue, 16 Mar 2021 16:20:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#47153] [PATCH v2] gnu: chez-scheme: Update nanopass to 1.9.2. Resent-From: Philip McGrath Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Tue, 16 Mar 2021 20:20: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: Leo Prikler , 47153@debbugs.gnu.org Received: via spool by 47153-submit@debbugs.gnu.org id=B47153.16159259699537 (code B ref 47153); Tue, 16 Mar 2021 20:20:01 +0000 Received: (at 47153) by debbugs.gnu.org; 16 Mar 2021 20:19:29 +0000 Received: from localhost ([127.0.0.1]:41131 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lMGA5-0002Tl-6k for submit@debbugs.gnu.org; Tue, 16 Mar 2021 16:19:29 -0400 Received: from mail-qk1-f172.google.com ([209.85.222.172]:38619) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lMGA0-0002TV-RW for 47153@debbugs.gnu.org; Tue, 16 Mar 2021 16:19:27 -0400 Received: by mail-qk1-f172.google.com with SMTP id f124so36664480qkj.5 for <47153@debbugs.gnu.org>; Tue, 16 Mar 2021 13:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=philipmcgrath.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=aS5SN2rZBT8g2D92UKCOPmNQ+KNtvg0N1M9Tx4WIC7k=; b=VWQNnDmRWLeVfxwqoT35LUA86ZDzeELy+FnTqJRa98nd+3HGgUiGjfZ5DqXaJERSR5 7YCEXC98BCnImLuD7BsKskN2mJ7ye4ouOcip12CGAGEU+FwoaFHsjGXGzULjWyGWk8WX fmCdEtad/lGc2dwT2D9DRyCP+DbtduQWuXc7WrJhREYn1h+GDsHAL8dRudxnYvMi+4sp NV5OqkZ3W+JUfiNFcwUcQ8afvbFU82aIzzql2q9yZxcS+kR1zeB9kvMjyaC75sIMjusv bd/H89xzwNsMn7y1e+i3atmk82nuhVj7NaLJmksdvk39A98r37DqFo8x1sZk3ieDQm6I Acsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=aS5SN2rZBT8g2D92UKCOPmNQ+KNtvg0N1M9Tx4WIC7k=; b=TddSZMJKK2GPkvqSz+Mc91te77Cl0E9jRg5AkUgigkThxFCNQhylWjMiHCWk9MjnEp hT2LGzTecdT8hGncZZ1jM7MRHBlleQ87ZaPZTfBIA6QE13Bed1a9JaN5qsEiDHW8lh1q sb+nEr3bSS0+QjYzbvAocYTIz+nrE33C9ovk/z8AzsrxDXRtHor3A8oOx9SCba9AK8RZ CTZ1JEWKrl1da1iVOhjnic1knOpERlHF1AzUzKMY9NA25pQNitj4Bt1WzLYqs3H/M0Mc Y8W6hBav0738hmyW/M1V0JC8hoSezHIfnqm1AA5KNu5BI1HM+nm/U3m2+LfYt/XM3vii Lkkw== X-Gm-Message-State: AOAM531rnRJtJL1ZaBqy4TCIkrY/WNKfeT+9fDOwOgBR5Y0kiRpW1Cr1 /uYMutj8FQ8X3b51rYs3Uf5lGl8dCsoGEdSCtII= X-Google-Smtp-Source: ABdhPJxDpOXeajh5768oTtz9U4yCZkgbYR2DD3vV2IMEShBgRJTCPe+cEiNf5lhK6eaq2zZClAmO+Q== X-Received: by 2002:a37:74d:: with SMTP id 74mr887624qkh.85.1615925958629; Tue, 16 Mar 2021 13:19:18 -0700 (PDT) Received: from Sapientia.local (c-73-125-89-242.hsd1.fl.comcast.net. [73.125.89.242]) by smtp.gmail.com with ESMTPSA id c5sm15907688qkl.21.2021.03.16.13.19.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Mar 2021 13:19:18 -0700 (PDT) References: <9581850ed011d311db0388fcda41f8fbcd479730.camel@student.tugraz.at> <20210315225302.6597-1-philip@philipmcgrath.com> <6e49888aaab2d2b2284d198eca51d0b9944be613.camel@student.tugraz.at> From: Philip McGrath Message-ID: <5a4d612f-445a-e3f0-a3ff-7abd4b021f16@philipmcgrath.com> Date: Tue, 16 Mar 2021 16:19:17 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <6e49888aaab2d2b2284d198eca51d0b9944be613.camel@student.tugraz.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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=1615926413; 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=aS5SN2rZBT8g2D92UKCOPmNQ+KNtvg0N1M9Tx4WIC7k=; b=L2K2XOfz1P+3pzD7HFMBlsPB1z1/IMXf3R9VpP85pOcwvUhPRLGnL88i4Baig/LVUAtUE/ DNolV9QBL4XxrarVrl9h5oFVL43f2q0vNQ9SXDgiyi32lCUGBJDI0TwU3+rBXRwnYPWg0i jpL7+wLnG0glz2q7q6ubXWbnEKvXANLdBb2QrARbsZ/SqPMNqvzKtnnZqdJUOTD2wrHUKc S+ka24YO4S9PxYqRjHcCsO30ml8GI4LUTCdW2VC8Tx2h0IbJHpFCjGUj5qbHJC8QVWM5zU dfeFas2qCYwT+vMF4yJPjqL7amKdmvAPVBBdPsEYO0csCKxbYSgLOq97ZRa08w== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1615926413; a=rsa-sha256; cv=none; b=SUOz7XaKq2FtoaJ66ehGTkY9kb7OvBsuE70ipotm449m6Flt1dux/BrnoMU6mBNOaSaKM0 msncHloI6bEk1o2NBHoeOl/klVhmoouASGTxjS6AxqGucqrdCJt5g3IgJgNwiMj6FaupD4 lVRtmkRI5hfWFkhgUU34d56UdcvYt+3rDKV6vPvWPYDCVh5ywGnX8nMVRzl82mA0bP3skk 22S0OK59SZzN4Svu5bldLZm4ghUyakOC9HHu4CX/fllNEr2q6Ne//sG+d/05/UE+WUTcdU FpgeIm1AWqOb+TyIH682o6d2BEkCfpEEKYMCT+2MxM8ywLv5VizbyKUxPJJQUQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=google header.b=VWQNnDmR; dmarc=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-Spam-Score: -1.40 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=philipmcgrath.com header.s=google header.b=VWQNnDmR; dmarc=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: 4C10121F87 X-Spam-Score: -1.40 X-Migadu-Scanner: scn0.migadu.com X-TUID: SPNsO4htsstu 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? >> - (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? > >> + ;; 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! >> + ;; put these where configure expects them to be >> + (add-after 'unpack 'unpack-nanopass+stex >> + (lambda* (#:key native-inputs inputs #:allow-other-keys) >> + (let ((patch-source-shebangs >> (assoc-ref %standard-phases 'patch-source- >> shebangs))) > I don't think you need patch-source-shebangs directly after unpack. > Those shebangs would be patched in their phase anyway – the only reason > we needed it before was because we delayed unpacking until configure. Right, thanks for catching this! >> + (setenv "CC" "gcc") > This should be determined via cc-for-target. Will do. >> + (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. >> + (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 … >> + (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. >> 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. 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. -Philip