From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id EJV7IGMxdGIQrQAAbAwnHQ (envelope-from ) for ; Thu, 05 May 2022 22:19:47 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id kGaoH2MxdGIwWwAAG6o9tA (envelope-from ) for ; Thu, 05 May 2022 22:19:47 +0200 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 0DCBF298FD for ; Thu, 5 May 2022 22:19:47 +0200 (CEST) Received: from localhost ([::1]:51360 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nmhww-00012F-6I for larch@yhetil.org; Thu, 05 May 2022 16:19:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59880) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nmhX4-0002Kg-Vr for guix-patches@gnu.org; Thu, 05 May 2022 15:53:04 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:52627) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nmhX4-0007sN-5Z for guix-patches@gnu.org; Thu, 05 May 2022 15:53:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nmhX4-0006Q3-32 for guix-patches@gnu.org; Thu, 05 May 2022 15:53:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#55248] [PATCH 2/7] gnu: racket: Fix out-of-source build. Resent-From: Liliana Marie Prikler Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 05 May 2022 19:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55248 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Philip McGrath , Maxime Devos , 55248@debbugs.gnu.org Received: via spool by 55248-submit@debbugs.gnu.org id=B55248.165178036824655 (code B ref 55248); Thu, 05 May 2022 19:53:02 +0000 Received: (at 55248) by debbugs.gnu.org; 5 May 2022 19:52:48 +0000 Received: from localhost ([127.0.0.1]:46524 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nmhWp-0006Pb-FM for submit@debbugs.gnu.org; Thu, 05 May 2022 15:52:47 -0400 Received: from mail-ej1-f66.google.com ([209.85.218.66]:45772) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nmhWn-0006PL-NJ for 55248@debbugs.gnu.org; Thu, 05 May 2022 15:52:46 -0400 Received: by mail-ej1-f66.google.com with SMTP id y3so10626710ejo.12 for <55248@debbugs.gnu.org>; Thu, 05 May 2022 12:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=UJObVC9udNbmrnVmX3fPegFIaynLbCPgjM0BDAuJtHc=; b=m7xzOd3j5tHCPTGsdUXbSUjeC/oKuw2X2U9aPJbOFhAVs6CCeKAHcTzPz3dYXl8QBF TkXPyRNeQKrd7JSoyGijY30ywaxsYsZWMz1gsLtDjoT3gyf+w3ZCx+XUgikkcDTyTK3F 3qavbvG4l9Fe6qWRn+652OHoR4XjAinukhG0sf5cr5yrH4WvnvsxgjUL7uLfW1FvyivM pOHeJMky9Chr3oyqzefHfg/7i29BqkyEBjPDPzke3RzvHvTJjnkgt9AinFY/wHZot+vK 6chO3ScpD1Rhx+1WGP2f/29SZWrw/R4lzGhbLIh9RonoGXn+udcWube0kNnR1IOD7fcv tP+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=UJObVC9udNbmrnVmX3fPegFIaynLbCPgjM0BDAuJtHc=; b=sZQbfwEC+XktN7Oh8qE5toY1KwCtoh6AaA+5rOAzo/JnRC4WAfVQEY6P82GKsfm4bB buAhhZ4hNoAS0AGy6BuaFNfHYQKw8jlVLYlvTcLYd5N7fWoRDaX/06qduijdNrF1mN4P tf6fWqW44EfGSqH5fKNfV9GabtCN7cTItTkLfsRMGxp1qvX7tz2mwqCjekVnwbx3CNGj pQtCjDbWxAeFhwSPaKxv5gRrha43XMuAkpaM8QZqicxGcd8a8YMnU+olicCtOoj4FYc0 HxFQgK5l223sCyLuR9QlU5dU/f3HcyHS2DoxVswu2FOEYuAsLuvZIBRVJhYXKpYIh2Bw VZlA== X-Gm-Message-State: AOAM532jts6oFS/BpxcgzewfNE/z3FnCjS7Nu6mikYLNQAKtaW3NBQTP HiABLG1D9b1awn5mWL8W+gM= X-Google-Smtp-Source: ABdhPJxgBkPD5FqPyycfTNE8lNmOMJYOYroBidfwYxOLJdFQ3WecxkEpPXtSBdHqonaMCctPj8sHmw== X-Received: by 2002:a17:906:4fce:b0:6f4:f41c:3233 with SMTP id i14-20020a1709064fce00b006f4f41c3233mr4801704ejw.117.1651780359662; Thu, 05 May 2022 12:52:39 -0700 (PDT) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id p9-20020aa7c4c9000000b0042617ba63casm1210054edr.84.2022.05.05.12.52.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 May 2022 12:52:38 -0700 (PDT) Message-ID: <72f621841c62c3663ee23371a91927e975617b80.camel@gmail.com> From: Liliana Marie Prikler Date: Thu, 05 May 2022 21:52:37 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 MIME-Version: 1.0 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 X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1651781987; 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=UJObVC9udNbmrnVmX3fPegFIaynLbCPgjM0BDAuJtHc=; b=CwImkzpOFIJCOxYYnnmx1qVLAiMIVVEvxxZ3yAf59greTfEgjPABh+scB9nmdMOg6EhTeo s50sOJknOApzRyJ6s0y1/5vv1dpV60i7n9WjSE5IRQclbqlY/r9AzvERRMPJ+2Te/mtSBA 5EoZngyfiNogCJu5d+u3UFcqKEu3gNWATDFJNPINl/zJxVrBNSi5sIuYVXU+k+FonclQFz EN8VG5jbwG7noqs/zhbfRj2tfsavU8nX+/k6twxuIXdev0xUX+Jd4cCbDuTegf0xDQ2dM4 dpGyXUlOJOKUpWvE5krvrcSu9KOZJyompPM630uR4R1ZrOWemEyvWE5DOuMgCA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1651781987; a=rsa-sha256; cv=none; b=DGGM1N5XBgaqcduJaZqoTawYHfzYgf889+WdwUWWtmjPubYU3hmwLrcz7h5FaaEPXssymm 7XJLwas5t0w0l2En0onlrmNIW1loT1MQipK7AI3eKfL4sC5hAPk0SFFtWq3c2Dd9Sd8Gp/ B/oMelMd1Rc62MXK6k7yfIjbaLwZND2KyWZWNl2WHmdepuW9pudVetwnyZm7PbRDJEZSJF PdR6vUqa22MxDVl7IXKqJYJOSJEAcrwmzfe9LxvYrb7Pw4Z4UmHNQeDSs6pdlaVQvi7ww1 B0RHBcs43Wwz9v6rxMFAYV0qTH3iULKT0miHxK9GLK2IKG4ud0sJO32bUU4bXw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=m7xzOd3j; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: 5.51 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=m7xzOd3j; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 0DCBF298FD X-Spam-Score: 5.51 X-Migadu-Scanner: scn0.migadu.com X-TUID: YAXcGFppq+XU Am Donnerstag, dem 05.05.2022 um 14:53 -0400 schrieb Philip McGrath: > Hi, > > On 5/4/22 05:29, Maxime Devos wrote: > > Philip McGrath schreef op di 03-05-2022 om 14:33 [-0400]: > > > -       ;; help with debugging, but it confuses `install-license- > > > files`. > > [...] > > > +             ;; workaround for install-license-files > > > +             (lambda* (#:key out-of-source? #:allow-other-keys) > > > +               (when out-of-source? > > > +                 (with-directory-excursion ".." > > > +                   (symlink "src" > > > +                            (package-name->name+version > > > +                             (strip-store-file-name > > > #$output)))))))))) > > > > Surely we could fix this bug/limitation of install-license-files > > upstream (in this case, upstream=Guix)? > > > > I'd certainly be in favor of that! I've never edited '(guix build > gnu-build-system)' but I assume that would be a 'core-updates' change. >   It would. > I'm also not sure what the best solution would be in general. > > In Racket's specific case, the source directory for the Racket VM is > (relative to the repository root), "racket/src/", where other notable > directories present include "racket/collects/" and "pkgs/". An > out-of-source build ends up happening in "racket/build/". The license > files are in the source directory, which is what install-license-files > expects, but the find-source-directory helper function fails to guess > the location of the source directory: I think the issue here is that we're in a chdir into the source, where the typical assumption that there's only a single directory besides it fails. > >   (define (find-source-directory package) > >     ;; For an out-of-source build, guess the source directory > > location > >     ;; relative to the current directory.  Return #f on failure. > >     (match (scandir ".." > >                     (lambda (file) > >                       (and (not (member file '("." ".." "build"))) > >                            (file-is-directory? > >                             (string-append "../" file))))) > >       (()                                         ;hmm, no source > >        #f) > >       ((source)                                   ;only one other > > file > >        (string-append "../" source)) > >       ((directories ...)                          ;pick the most > > likely one > >        ;; This happens for example with libstdc++, which lives > > within the GCC > >        ;; source tree. > >        (any (lambda (directory) > >               (and (string-prefix? package directory) > >                    (string-append "../" directory))) > >             directories)))) I don't think (lambda (directory) (and (string-prefix? package directory) (string-append "../" directory))) does what we think it does. Even so, it's debatable whether that works for Racket. > Some possibilities I can imagine: > >    * We could add a case to find-source-directory specifically for > "src". Not a fan personally. >    * We could change configure to communicate the location of the > source directory, e.g. via an environment variable, rather than > trying to guess. That would work, but gratuitous environment variables could have unexpected consequences. However, note that the build systems themselves already need to capture the information of where the source directory lives! For gnu-build-system, you could check for abs_srcdir in the Makefile for instance. If this ever becomes necessary (reading ahead it doesn't seem to be, but let that if be an if), I'd suggest splitting install-license-files into a helper procedure that assumes we're in the correct directory and a top level procedure, that performs the guess. This top level procedure would need to be implemented once per build system, while the helper could be inherited. >    * We could change install-license-files to do more searching in >      general, e.g. trying multiple directories or preferring a > directory that contains at least one match for > #:license-file-regexp. We'd have to consider the potential for > false positives, too (e.g. sibling directories with projects > under different licenses.) >    * We could add an argument to install-license-files to specify the >      directory explicitly, as a complement to #:license-file-regexp. I would not do either. An alternative to adding another phase is wrapping install-license-files in a directory excursion within this package. That'd be less code which achieves the same thing. > Another scenario that might be worth considering is projects that > follow the REUSE specification[1], which I don't think would be > handled by the current install-license-files. I don't think we can rely on projects consistently following them, sadly. > But actually, for Racket, I forgot that a patch I'd sent upstream to > handle this in `make install` should be in 8.5, so we may not need > this patch at all: I'll confirm before I send v2. That is of course the best solution :)