From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id gPv5L3KrT2AXYgAA0tVLHw (envelope-from ) for ; Mon, 15 Mar 2021 18:46:10 +0000 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id sF2tK3KrT2BNBAAAB5/wlQ (envelope-from ) for ; Mon, 15 Mar 2021 18:46:10 +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 42CD11ADB4 for ; Mon, 15 Mar 2021 19:46:10 +0100 (CET) Received: from localhost ([::1]:56290 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lLsED-0006BZ-Bk for larch@yhetil.org; Mon, 15 Mar 2021 14:46:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43742) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lLrxg-0007Yh-QD for guix-patches@gnu.org; Mon, 15 Mar 2021 14:29:04 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:53767) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lLrxd-0002Dq-NE for guix-patches@gnu.org; Mon, 15 Mar 2021 14:29:04 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lLrxd-0005Qq-Kk for guix-patches@gnu.org; Mon, 15 Mar 2021 14:29:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#47153] [PATCH] gnu: chez-scheme: simplify packaging Resent-From: Leo Prikler Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Mon, 15 Mar 2021 18:29: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.161583291820850 (code B ref 47153); Mon, 15 Mar 2021 18:29:01 +0000 Received: (at 47153) by debbugs.gnu.org; 15 Mar 2021 18:28:38 +0000 Received: from localhost ([127.0.0.1]:37080 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lLrxF-0005QE-Ku for submit@debbugs.gnu.org; Mon, 15 Mar 2021 14:28:38 -0400 Received: from mailrelay.tugraz.at ([129.27.2.202]:40703) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lLrxC-0005Q5-QU for 47153@debbugs.gnu.org; Mon, 15 Mar 2021 14:28:35 -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 4DzlKq4RhDz3xBl; Mon, 15 Mar 2021 19:28:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1615832911; bh=MqwtT5uxhBScQCrIhvnCm2qSjowA0f5yR5mGpW/PStQ=; h=Subject:From:To:Date:In-Reply-To:References; b=lwppmeKVLdgICB/ZjRxbIuSFe3x0b/iSHsMZkOnnoqgyd1ZxTGzREa9cTJvYYjJXx 8f238sumXYX3Vpv7FGknxBKk8+MKLQyXWm1J5tqQa3LcBrcz2JfJw8MhpCXkMlYSbm 9LB8r+Hz8VPG9oC6uTvK9/qdCehkpOmffm9OH04g= Message-ID: From: Leo Prikler Date: Mon, 15 Mar 2021 19:28:30 +0100 In-Reply-To: <80ae553f-ac34-9b63-af43-9adf7d7113a6@philipmcgrath.com> References: <20210315084235.7051-1-philip@philipmcgrath.com> <80ae553f-ac34-9b63-af43-9adf7d7113a6@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=1615833970; 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=MqwtT5uxhBScQCrIhvnCm2qSjowA0f5yR5mGpW/PStQ=; b=SBou21QpuRNQZ+ZE4tXWwrJCdadtrtiJBZ0t/dj6sNp4B00hSRF7WnPTmpDItHUtjLTpEx 45P7tZGT5Z7VRy8y1/HO9Sa4rFXbSh+qQJkzoyevRtmPvlUcXsp9aVLYs9JVSFpya2GrlG q2DNs71g83okwIwNbtG8pSeSH2akTlGCHUNJXvQJQE/2xCwKxpl5emirSh6QH4Avv+I/X5 WwAZn5p8MiHTXhgvSdM+xek/pedq/cMGVQrh7tjHXTHBF9tswcfcq4gWmSybZxQ+E+OmHZ Wr7njzZGZPE4PKuh0Or9sLU+tqqF60vY3MrgGIQ9+MuFYoMmqmurNJnfbdhJ3Q== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1615833970; a=rsa-sha256; cv=none; b=ulkl5+NN8OiYHLvKz7m87CAa42A7fqFzIAsQy8u7YhGTuG+bZhjpTUFTssgGouTJVNQsKh MCZaKLFucaxsmPDSbf1gsFQ9zArBbKgdsKqzC8feSkDoisV+VMWKZ26O4kIIqyVEaMi3sF p2r/va5UeQi4kAkk0broz1cV4Fkq7gAhOo/G/tYIKb1piyvcA9OegfKBZsObefqfA+Sc6p EnL74TBmbgOYO6ZiR9vPM1DIw1PHUpl7RFLiL9U3sZ6IWzcqlV7w+/mWqyrHzwUP7UM5UZ IrF155tmLXqXgizufHWAxQGSU9l4OX5j2uI+yZJSLl8UIeTNKrdJXbWJpYjQDQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tugraz.at header.s=mailrelay header.b=lwppmeKV; 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=lwppmeKV; 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: 42CD11ADB4 X-Spam-Score: -1.30 X-Migadu-Scanner: scn0.migadu.com X-TUID: JQ8A/SpZ3eQG Hi! Am Montag, den 15.03.2021, 14:03 -0400 schrieb Philip McGrath: > Hi! > > On 3/15/21 6:32 AM, Leo Prikler wrote: > > I'm not an expert on Chez Scheme, so take this with a grain of > > salt, > > I'm not an expert on Guix, so take this with a grain of salt :) > > I've been exploring packaging for Racket, and, by extension, Chez > Scheme, as a way to get more familiar with Guix. Hehe, I see what you did there 😉 > > Am Montag, den 15.03.2021, 04:42 -0400 schrieb Philip McGrath: > > > * gnu/packages/chez.scm (nanopass): Rename it to ... > > > (nanopass-framework-scheme): ... this variable. Change it from an > > > origin > > > to a package. Update to 1.9.2. > > What advantages do we get from making this a package? Can it be > > upgraded to 1.9.2 without this change at the same time? > > > (stex): Rename it to ... > > > (chez-stex): ... this variable. Change it from an origin to a > > > hidden > > > package. Update to commit 5405149, which helps us install it. > > Same here > > I don't have a strong opinion about whether these should be packages. > My > main goal was to have the unpack and patch-source-shebangs phases > happen > just once, rather than be handled in an ad-hoc way inside chez- > scheme's > configure phase, because I know I will be reusing these in the > Racket > package, as well. I think your worries might be a little unfounded; adding more phases between unpack and patch-source-shebangs to add additional sources might not be the most common pattern in Guix, but it's certainly not a rare one either. If you've ever played a trading card game, you might call it "uncommon" 🙂 > There are some other considerations specific to each package/origin: > > - nanopass-framework-scheme is portable to many R6RS Scheme > implementations. It doesn't have a Makefile or anything: > you just put it in the right place and then happily > `(import (nanopass))` from your Scheme of choice. Which makes even more sense to have it as origin. Suppose you were to actually bytecompile it with both say Guile and Racket, then you'd have a guile-nanopass and a racket-nanopass both with the same origin. > - I think the right thing would be to make chez-stex a > public package, instead of the "stex" output of the chez-scheme > package, but there are some bootstrapping issues I'll discuss below. I agree. You can use the origin as an input to chez, like we've done before, then use the already built chez to compile stex into chez-stex. I don't think the latter half needs to be done right now, though, you can delay that until you feel more experienced in packaging. > > , also does this need to be done at the same time as the > > nanopass upgrade? > > No Then you should separate this into more than one patch. > > > (chez-scheme)[source](patches): Use it. > > Use what? > > The new patch chez-scheme-build-util-paths-backport.patch added > above. > Is there a better way to write that in the message? It is not clear, since you've mixed up 3(+?) patches into one. Yet another argument for separating your patches 😉 > > copy-build-system exists. And again, what is the point of making > > this > > a package if it contains the exact same files as the corresponding > > origin? > > copy-build-system also does validate-documentation-location and > install-license-files, IIUC. But again, I'm open to alternative > approaches. Since I don't really see the point in making it a package anyway, you can keep it as an origin imo. > > > +(define chez-stex > > > + ;; Hidden because of a circular dependency issue: > > > + ;; stex needs chez-scheme to be used, but chez-scheme uses > > > + ;; stex to build its documentation. > > > + ;; The chez-scheme package has an stex output that exposes > > > + ;; the useful version of this---or maybe there's a more elegant > > > solution? > > This is related to the comments I added about things probably being > wrong for cross-compilation, though I don't think they're any more > wrong > with this patch than without it. Fundamentally, you need Chez Scheme > to > compile Chez Scheme. (The Racket fork can be bootstrapped with a C- > based > Racket implementation that simulates enough of Chez Scheme to > compile > the Chez Scheme compiler. Unfortunately, the forks have diverged too > much right now, at a minimum in the definition of `#!base-rtd`, to > be > able to bootstrap upstream Chez that way.) > > Chez distributes "bootfiles" for i686, x86_64, and "arm32" (which I > hope, but am not sure, could work for "armhf"). Once you've done a > native build for one of those platforms, you can use it to cross- > compile > for any platform Chez Scheme supports (ppc32, various BSDs, > etc—Racket's > fork adds arm64, and there's been some work on riscv). You need Chez > to > build stex, and thus you need a native Chez to build the Chez Scheme > docs. The way this would typically be solved in Guix would be to first build a "minimal" variant of Chez without documentation, then use that to build the full one. See also glib as an example, where such a situation occurs. And yes, unless there is a good reason not to, the minimal variant would be hidden. Calling back to your earlier definition of chez-stex, you could use chez-minimal to compile the (publicly exported) chez-stex package. Regards, Leo