From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id A8FD0138334 for ; Tue, 22 Oct 2019 08:16:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A659BE0986; Tue, 22 Oct 2019 08:16:45 +0000 (UTC) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BCBAAE0986 for ; Tue, 22 Oct 2019 08:16:41 +0000 (UTC) Received: by mail-qt1-x841.google.com with SMTP id w14so25454987qto.9 for ; Tue, 22 Oct 2019 01:16:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=XpF7QG6JzsPYTjwqXg3OTXYfDngwa4k75sfP7cP6qSY=; b=WGLzsz87WM5Fg3+1EKJALccnT0+FFLnRtVwCG48wOubhQVroKS4OfPWhHZJ6g/RHr8 SwQMAK1sQxLLobOJq0V0QnUBBJAtoDQD4CsRI67ZT1KkVEF0dtq0Onf5PBZk2kKSyfjg EEymt3NpQUK1hldq4ycrs2h8pHYfSOMvDN/qNLRjvI5CADITQ0ZmiY6ny1SxU2QPsX/S kX7jj8uZXMI3YGr1souAJtIZCRK5Q6rn/y8QNTY/HyqM4W9WaxhsHJNgNDUmh9w+ZO4G Jg9A+bwM9TH0KraZgZSlQ2fJr5U6nqBM5mAjNQw8xlVGa2o7MGHvUmmPxpdx1Decteru h6Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=XpF7QG6JzsPYTjwqXg3OTXYfDngwa4k75sfP7cP6qSY=; b=tWi0P7SRdhbuwGhOsad3mVXDlLSRd7eseu6vFndZwiYmRMEYp9/d+r2HXD1OcNfJQJ Cc8JvMLIrpwpRrqHcE8hiM/nVJMnlbFv8NPY5fJBfbGM9rWb74Yxr5w3p1a2mh0lihcz CwrChUKsJkD0bybmkyZ7gOscyGV9NmZQgnMXrYbDqttehSj6hQJHQTiksEF7ZK/2CVsu 6yNu55Z1LbuAc76LYkbu93KNlKipAMVkwTbagzJpJff3rW/+uCSR4fUgxHb3hZc5p2lr 3uaUMPYsyiBKasuu0t3OK6fxmeS6HFZCqO7VvMICN22XTQiEMXxfbQysZp+U8j8RWBst s+HA== X-Gm-Message-State: APjAAAXwOQ4ra8QJe/yoeuURVuVY4efs17reGxPVPv1xGURcUXAklomZ izMJVDN10cJIcFyCvBZ1hnRLZZVMRtKyqQ== X-Google-Smtp-Source: APXvYqwI2B1AzaQqQOwXTVxYb0KGvT9oRr96VDPnXdpwykaVjWGYAr3rD4d8dcUY5wvYdHw8QELw7g== X-Received: by 2002:a0c:c10d:: with SMTP id f13mr1926067qvh.88.1571732200640; Tue, 22 Oct 2019 01:16:40 -0700 (PDT) Received: from localhost (tor1.cloud-neutral.org. [23.140.160.28]) by smtp.googlemail.com with ESMTPSA id i13sm6609836qkk.18.2019.10.22.01.16.39 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Oct 2019 01:16:40 -0700 (PDT) From: Akater To: gentoo-lisp@lists.gentoo.org Subject: [gentoo-lisp] SBCL bootstrapping support (again) Date: Tue, 22 Oct 2019 08:09:22 +0000 Message-ID: <87y2xdurpp.fsf@gmail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Lisp mail X-BeenThere: gentoo-lisp@lists.gentoo.org Reply-To: gentoo-lisp@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: dc0793b5-1bad-4a92-a113-1897d85f5284 X-Archives-Hash: fb2d8a8e36983b9c8bd40f36d2c3d7d8 I have raised the topic of sbcl bootstrapping some months ago on this list: https://archives.gentoo.org/gentoo-lisp/message/c6c615f31f29027e0f7d0f98199= c65dc That time, I only considered bootstrapping because it felt closer to Gentoo way. Now I'm going into this again for rather more pragmatic reasons. I recently tried a uClibc hardened profile. It worked better than I expected but there were some issues, and one of them was emerging sbcl. The shipped binary wouldn't run so normal build failed. Thus, I believe a bootstrap support is necessary after all. I'd like to discuss my approach to introducing bootstrap feature to the ebuild. It had been tested: I emerged sbcl built with clisp. The overall changes ended up being sort of involved, which is why I'd like to discuss here first, before attempting a PR or creating a Bugzilla entry. I don't have much experience with ebuilds, and I prefer things customizable, so my proposal might be too much. I added the following USE flags: - a `bootstrap' flag which triggers the feature - seven flags to specify seven possible compilers, all mutually exclusive according to REQUIRED-USE - a `bootstrap-self' flag which tells the newly built sbcl to recompile itself prior to install In addition, a compiler does not have to be specified on a USE flag level, namely: when no compiler is explicitly set, the compiler is assumed to be `lisp', which means =E2=80=9Cdefault lisp,=E2=80=9D and a sym= link `/usr/bin/lisp' is to be governed by `app-eselect/eselect-lisp'. sbcl-binary is not fetched when bootstrap is set. Regarding the linked previous discussion of sbcl bootstrapping here, I believe the issues mentioned there could be mitigated by adding ewarns along the lines of "You've set the bootstrap flag. Don't send bug reports!" but this might not be enough if sbcl built this way is then used to compile other ones. "Don't send us bugreports EVER until you -bootstrap and it succeeds" could then do the trick, I guess. "NO BUG REPORTS PLEASE" could be added to the flag description as well. Now, to the more problematic stuff. One particular decision that one might find questionable, was providing USE flags for all lisps, even though it's not clear if sbcl can be bootstrapped with them at all. While in some cases it might make sense to remove USE flag until better times, I believe having them all present is reasonable, as sbcl is expected to be bootstrappable by any ANSI compliant Lisp. Which is why I believe it makes sense to mask these USE flags on a profile level if necessary, and only if persistent problems with the corresponding lisp are encountered, or if it's not ANSI compliant (at least in some practically feasible sense). Furthermore, their presence makes a tester's life a little easier, even if just a little, and for some testers, it could be more than that, who knows. Another questionable thing is `app-eselect/eselect-lisp', more so since it doesn't exist yet. I believe it does have its uses outside of this particular issue---e.g., it would allow for shipping a simple default working config for SLIME when SLIME is installed from Portage. Clearly, packages for other applications written in Common Lisp could employ this. It might be necessary to replace `eselect-lisp' with `eselect-commonlisp', ditto `/usr/bin/lisp'. I hope it doesn't have to be like this. What do you think?