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 ms0.migadu.com with LMTPS id uEiFOFtSN2H0HwEAgWs5BA (envelope-from ) for ; Tue, 07 Sep 2021 13:51:55 +0200 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 sGpgNFtSN2HOQAAAB5/wlQ (envelope-from ) for ; Tue, 07 Sep 2021 11:51:55 +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 E8DC62B38B for ; Tue, 7 Sep 2021 13:51:54 +0200 (CEST) Received: from localhost ([::1]:47528 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mNZdp-0003UX-Vr for larch@yhetil.org; Tue, 07 Sep 2021 07:51:54 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34266) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mNZc8-0001zT-FG for guix-devel@gnu.org; Tue, 07 Sep 2021 07:50:08 -0400 Received: from michel.telenet-ops.be ([2a02:1800:110:4::f00:18]:42844) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mNZc5-0006F7-QC for guix-devel@gnu.org; Tue, 07 Sep 2021 07:50:08 -0400 Received: from butterfly.local ([188.188.3.227]) by michel.telenet-ops.be with bizsmtp id qzq12500N4tskic06zq1Dz; Tue, 07 Sep 2021 13:50:02 +0200 Message-ID: Subject: Re: Rethinking propagated inputs? From: Maxime Devos To: Liliana Marie Prikler , guix-devel@gnu.org Date: Tue, 07 Sep 2021 13:49:56 +0200 In-Reply-To: <7522a0488c02f459a02bf0aa9e6a36d9d8f31d0b.camel@gmail.com> References: <045891c151c74e0d66d91973c9e55e0194272df5.camel@gmail.com> <5ba200792813bb0967e388911320b741cf98d90d.camel@gmail.com> <4de577e44d3d7e4099266646f0f20686bb111f08.camel@telenet.be> <516610cf66bec9320406d592bd309c6f876abece.camel@telenet.be> <7522a0488c02f459a02bf0aa9e6a36d9d8f31d0b.camel@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-OAskX8RTywiDKlkVKf8M" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r21; t=1631015402; bh=rqtAGEvW5p5zaalsWJx7Vd9Wpe5CWgPiLkKvELX/jbM=; h=Subject:From:To:Date:In-Reply-To:References; b=OjNySjwVJw0hwNrdE4qKoyWVkjaCnSqPlK5XOC6BbcTBI2TKIpz3pNOdChmImzhkj PPHvmLMTWX2qjQQGOSjrE4vTu3yx3EctZkaDUbQ4snmdhVWy5HlKD3RgblaPuTXcZt L62mdp1r2e2qiKeJDACnnn/1GT4WeObWZn2ZTU68VTACebNvrbP5ssAv2F+uC4+Hhx xlqYfqyIy7NmHh/n6kCbG+w1RlSD2RBMzd72osFOzVAATtdQHqv+ZIQae+4RhLTwGg U0uOCi04Gk46Fyl7PxrWMHIZu3tfVfviH3kt7ALyyRtMk5qYZmn+EFz58zx+YGT7O9 OiTV8nShvpGkQ== Received-SPF: pass client-ip=2a02:1800:110:4::f00:18; envelope-from=maximedevos@telenet.be; helo=michel.telenet-ops.be X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1631015515; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=rqtAGEvW5p5zaalsWJx7Vd9Wpe5CWgPiLkKvELX/jbM=; b=nvd6PkIaE47sW7f9b6U4ktS1N7lE7UsIoRqSyHiiUIHt09Jm7cMNqVBv6dBuvBfv127Bu6 Er3fYQDA9zrcOzX3pY2mLX8mYKuwhcKN/gy+9lLQFeDBlZ13wZM/XENIymWVTICTvTR2A3 6tr7nkhoSAMYU8KRKQ8IsKQ+dijIRiw0xirHBE/uc6ltO3RWFFlqXHxO4pjmmq/Ck8H3ML OSUIX6vKKiu0jAT5hXt/igVI8bpEolxS1BC/93NtRal0/vnZT1NziED1oOTVrb8BskK33N V97rc4vO4hB4SzbK2/RBEdGZbU2LfADaumqJjFRbyojdMWWRfubbl4kNQ9RH4A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1631015515; a=rsa-sha256; cv=none; b=GW0vVPBOmrngdh0ga8zMBnElHujR/aihxCwlzFs3yBwxCHSprfmDYappXeC7/nlQDdt5eJ EBBSFBm/GQaMRnmjrSRAYPlixGrHzUUa68Q1XlnnYn3uIrOWQ+stTIDem6bsegXHT4uStN dxd0g5+JtyXnqXajqLrNtQ771nh2ywJfqwQS5UipmG26sqq+AECnCqa7HYBDPV3iKIt8ce H3rVmaPxiixi9OjndrhEQqpgzkqW00L8whKlwngiPHSIyRLT3K6amKEtFHVxOca1kY6cdA 4szhwHuWX/1m+gLIKa4rwUt/YDiLWon1pev/KJqh04fi9Jl72fFLU52+vYVzSA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=telenet.be header.s=r21 header.b=OjNySjwV; dmarc=pass (policy=none) header.from=telenet.be; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Spam-Score: -2.71 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=telenet.be header.s=r21 header.b=OjNySjwV; dmarc=pass (policy=none) header.from=telenet.be; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: E8DC62B38B X-Spam-Score: -2.71 X-Migadu-Scanner: scn1.migadu.com X-TUID: N2N4qFe9l7HW --=-OAskX8RTywiDKlkVKf8M Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Liliana Marie Prikler schreef op zo 05-09-2021 om 23:10 [+0200]: > Am Sonntag, den 05.09.2021, 22:27 +0200 schrieb Maxime Devos: > > Liliana Marie Prikler schreef op zo 05-09-2021 om 21:37 [+0200]: > > > > > I must admit that this solution appears to have some surface > > > > > elegance, but what exactly would go in the "build" output of a > > > > > package? You mentioned pkg-config files (obviously), but those > > > > > don't suffice to actually build a package, do they? > > > >=20 > > > > Sometimes they do suffice. The .pc files contain the "- > > > > L/.../LIB", "-I/.../include" and "-lstuff" flags needed for > > > > compilation. If the build system of the package uses pkg-config,= =20 > > > > it will use those flags, so the compiler will find the library in > > > > that case. > > > >=20 > > > > Not sure if they always do suffice. > > >=20 > > > Is that so? I would think the build process needs to see stuff > > > outside of its inputs for that to work, e.g. the actual header it > > > wants to include, which isn't part of "build". Am I > > > misunderstanding our sandbox requirements? > >=20 > > The .pc file includes the absolute path to the library and include > > directories, so the output "build" with the .pc file has a reference > > to the output "out" with the libraries and include headers. More > > concretely, take the .pc from the glib package: > >=20 > > prefix=3D/gnu/store/98hgv3i6hdqgiq98ldy7rkpdwhah8iq2-glib-2.62.6 > > libdir=3D${prefix}/lib > > includedir=3D${prefix}/include > > [more stuff] > > Requires.private: libpcre >=3D 8.31 > > Libs: -L${libdir} -lglib-2.0 > > Libs.private: -pthread > > Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib-2.0/include > >=20 > > The (transitive) references of all inputs to the build process are > > included in the sandbox. In this case, if the package has the > > hypothetical glib:build among its inputs, the daemon will > > automatically make glib:out available as well in the sandbox. > And IIUC if glib had a "lib" output, glib:lib would be available in the > sandbox instead of glib:out due to the reference by glib:build? If a package has the proposed 'glib:build' in its (propagated-)inputs, and if 'glib' had a 'lib' output, then in the build sandbox of the package, 'glib:lib' will be available. > If > that's the case using #:by and "build" outputs might be a preferable > solution, if not for all packages then at least for some. > At this point the question then becomes what to name this "build" > output and what to put into it besides pkg-config stuff. Particularly > in the land of glib, there also exist typelibs, which can be used as > "build" inputs in the case of Vala or as runtime inputs in the case of > pygobject and other language bindings. Perhaps this is early > bikeshedding when we'd actually need to code up #:by, but what would be > the better approach here? Separate "build" into "pkg-config", "cmake" > (for CMake-based package discovery), "typelib" etc. or have one more or > less anonymous blob called "build"? I don't know (-:. Maybe let's just start with pkg-config and #:by? for now? The name can always be changed later. Greetings, Maxime. --=-OAskX8RTywiDKlkVKf8M Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYTdR5BccbWF4aW1lZGV2 b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7jPLAP0ccSDJsd05QW84xRQLb1EOae3C 2Xd6s1FERsjBz0nj8QEA5ntZdmotpNN0VU6oodDtj7B65wmFRQXCvoiFeXxtjgM= =W3YS -----END PGP SIGNATURE----- --=-OAskX8RTywiDKlkVKf8M--