From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id wMbrCuORRGETHgEAgWs5BA (envelope-from ) for ; Fri, 17 Sep 2021 15:02:27 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id GLy2BuORRGHYYgAA1q6Kng (envelope-from ) for ; Fri, 17 Sep 2021 13:02:27 +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 670AC16717 for ; Fri, 17 Sep 2021 15:02:26 +0200 (CEST) Received: from localhost ([::1]:58772 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mRDVZ-00071K-Cr for larch@yhetil.org; Fri, 17 Sep 2021 09:02:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46094) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mRDVC-0006zh-EO for guix-patches@gnu.org; Fri, 17 Sep 2021 09:02:05 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:47188) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mRDVC-0004rQ-6i for guix-patches@gnu.org; Fri, 17 Sep 2021 09:02:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mRDVC-0002c2-2V for guix-patches@gnu.org; Fri, 17 Sep 2021 09:02:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#50627] [PATCH 0/2] Make wayland-protocols dependency native-input. Resent-From: Liliana Marie Prikler Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Fri, 17 Sep 2021 13:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50627 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: muradm Cc: 50627@debbugs.gnu.org Received: via spool by 50627-submit@debbugs.gnu.org id=B50627.16318836759983 (code B ref 50627); Fri, 17 Sep 2021 13:02:02 +0000 Received: (at 50627) by debbugs.gnu.org; 17 Sep 2021 13:01:15 +0000 Received: from localhost ([127.0.0.1]:58734 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mRDUQ-0002aw-RN for submit@debbugs.gnu.org; Fri, 17 Sep 2021 09:01:15 -0400 Received: from mail-wm1-f68.google.com ([209.85.128.68]:44022) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mRDUO-0002ag-Pi for 50627@debbugs.gnu.org; Fri, 17 Sep 2021 09:01:13 -0400 Received: by mail-wm1-f68.google.com with SMTP id a194-20020a1c98cb000000b0030b41ac389fso2107025wme.2 for <50627@debbugs.gnu.org>; Fri, 17 Sep 2021 06:01:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=lVYa442mbttea6Ca0EeFrhhm1u5kUigDtjd1UVFFN9A=; b=meuQOWgJkoYF1tPH0Yq2+myrK5d+UYz+zAwrJwSo+aIYeOFnqyoHkGC6hTT9fs/sLo g1fianNSKPGmNzuVEQ8c0TN45C5SF4ObSK1SH17mHeedOlNx81w+o9txfttiICEwHAD1 TbM/fRdCxI2ao4YxyzlhqvFBPomzrromahmnnIEyMgpoMzp/PY5f+DXENExjAyzijYT/ 2Ph2//Ap3MeX2d9ecui9YtdttmbmVnACkSznDbMhzKCGnM8DN5qmupckXg63JdM4hpdx T59ptTIU3KRZQoTpI9RJ1qECoovIkmQihdtXqzTOiu4FMb7v3uhRcRo6atb/Ds9E3+Rz Fyfg== 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:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=lVYa442mbttea6Ca0EeFrhhm1u5kUigDtjd1UVFFN9A=; b=4TIrPKJQTpcDdRcBW7DdJPq4AdLSZttHr12Ur7IZP/xUvyZCGLIKKN0OcXzBpGKhwC erLrORmiEU8VWs1CrK3/bThN5+MQsm67BYsGMepT6D+bKBlhnFNwne2OWUF9KaukxfkW Ixwzp8W5vfT5EpaE+BJhsTnUx43xVoWCthAM7YyJo3gfF1vw1WVyOg87DyG7zB4USZRV HcUNvLOKaWnz0eUUhqI8kPcS496afE/93ZGrKBd7EbDZu10wnaU5bFjOpTTpjACk8VAr 5xflmGsD2+7JGQXtAUw8gzPTtyjGfW5NfZRG0UOyxR8WoMpzmM2hsMeuCbnHTvXxziH2 GtAA== X-Gm-Message-State: AOAM532wjSGNorl2W3DqJeGVi/j7bpwsWJCOyIVCbHLQkPaXCRjVkYNb LmJowNmXaPuckJ1RTV/+aHk= X-Google-Smtp-Source: ABdhPJyUZPIhfc2dPTeYeA5V34RJmIZFY0/Xh4EzwV+l7OkEuseCEZ6GPytOhXivp1Tclr0GQG5TKw== X-Received: by 2002:a7b:cb45:: with SMTP id v5mr14561607wmj.184.1631883666526; Fri, 17 Sep 2021 06:01:06 -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 s24sm6070712wmh.34.2021.09.17.06.01.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Sep 2021 06:01:05 -0700 (PDT) Message-ID: <830e045c54e06b0b0beaee30837f575a25cec986.camel@gmail.com> From: Liliana Marie Prikler Date: Fri, 17 Sep 2021 15:01:04 +0200 In-Reply-To: <875yuzfqqw.fsf@muradm.net> References: <20210916192331.29606-1-mail@muradm.net> <87ilyzg96v.fsf@muradm.net> <4bb63f130f3ec7dac628a8139c405cdc202412e9.camel@gmail.com> <875yuzfqqw.fsf@muradm.net> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1631883746; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc: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=lVYa442mbttea6Ca0EeFrhhm1u5kUigDtjd1UVFFN9A=; b=L6ETS75VXaHVibYGit6zQT2FemsYMH3BA4YsMuf89DgIBGfd+IbN6C+u1M6/Seeo0AyXJt 0ZGgyu1betRPk0cMMyeQNnN+bbuiLnhETA/jylA4D8Mrnh3FTi5Y27osgBO+fJpkD2qNVU VYGX1BMuUco6k2ta07caoNy/XvY44I/Tuxu4sM1SNtKdh4Vwyszni6jHAu1BRgA59qTz5r Xpxq6yq3PBM+A4OMdtYqqsCu1F8MR30ujgFx6pXqb+JSF8qrt1zFSV/vBcVg9UU42250uW GIc9hEb3/hlQ2B9EacKUqVP+5HlM/g9VCbU8jz/U2LTRGye7qo5X68Q/fJr/wQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1631883746; a=rsa-sha256; cv=none; b=KR14He6+BUUj8L3nZqOUH1ELt4iyTu+onKQkbJ4dnsCxpSiTSQP0BrRpZI2Ywg1KSrUmiU HPrTtJn0/IJAGPWkgkXUqJTRl0MMMW/Ek+g/xFKHRgtHWuDYluoVsG0EGjYjPxruQPLToQ IJB+PM0q3xGtBOoX0J8xuHpOl+HPbF5cPtSmj6c/VPPkU4gHbj42dTJkWW4igaRcUDTTc9 wG4WiuMuyBi3v+2uZkrmCmoMVftNzzQzs1ol2dvkE8q+5fV0xAX7WuDqEAxwSICASBg3Dv K32usft3Ycp1HdMwE5el6ZfyTWJFiHCdYBc/bsIXCK0zleSGPmYDtgMVQFjCrg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=meuQOWgJ; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (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-Spam-Score: -1.30 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=meuQOWgJ; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (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: 670AC16717 X-Spam-Score: -1.30 X-Migadu-Scanner: scn0.migadu.com X-TUID: lbOi7ELxN66l Hi, Am Freitag, den 17.09.2021, 11:20 +0300 schrieb muradm: > Regardless of comments below, I understand what you are trying to > point out. It is fine with me to use 'inputs instead of 'native- > inputs, as the final result won't change. Just in my opinion, what I > found it that, it need/should not be in 'propagated-inputs. I will be > updating the patch to make sure that wayland-protocols are listed > among 'inputs without propagating. It is also fine with me to close > this issue and don't do anything if you say that it is unnecessary, I > don't mind :) I agree that reducing propagated-inputs is a good thing, it should just be moved to inputs. When you update the patch, please do use the upstream version of gtk3-wayland-protocols-dependency.patch. > Liliana Marie Prikler writes: > > > And what kind of code is generated from them? I would assume > > it's target code. And since wayland-protocols is no tool to > > process those XML files, but the files themselves, I'd hazard a > > guess that it should rather be built for the target. While > > currently this appears to make no difference, there might well be a > > time in which those files differ for some two architectures, which > > then would cause problems in cross-compiling contexts were it a > > native input. > As with any other kind of protocol, you can implement platform > specific encoder/decoder, but protocol remains the same. Suppose, > connecting from arm, to x86 or vice versa in the context of wayland, > should protocol change? As you mentioned wayland-scanner below, that > would be its task to interpret protocol specification in platform > specific way. So I would speculate that in future these > specifications would remain the same. > Otherwise, that would defeat the point of having protocol. You are probably correct in that those files will likely stay the same for all platforms, but there could be scenarios where for the sake of performance or whatever else you might want to have some protocol extensions. Platforms that don't support those then wouldn't ship said protocol extensions. > > In that case I'd hazard a guess that it's fine, but the phrase > > "wayland-protocols remains to be an input" is perhaps a bit > > weird given the change to native-input. > Probably, I'd better put single quote in front of the word when it > means symbol, and don't put one when it is human word :) in this > context it was meaning literal input (regardless of type, be it > 'inputs, 'native-inputs or 'propagated-inputs). In my personal experience people don't pronounce quotes, so it's better to be explicit rather than implicit. > > > There are two things which are being changed. First as you > > > pointing out is the way Guix treats it, i.e. reducing closure, > > > etc. Second is propagation of inputs. Currently (without this > > > patch), since it is listed in propagated-inputs (and also > > > advertised in .pc files), wayland-protocols as requirement, > > > needlessly, getting pushed down then hierarchy. > > We ought to move it from propagated-inputs to inputs and either > > (if we can) ignore pkg-config or patch the pkg-config > > files. W.r.t. pkg-config I do wonder whether Requires.private > > needs propagation, though, it normally should be just Requires. > I suppose, it is not in Guix's hands to control how pkg-config > files are authored by software owners and/or interpreted by build > tools. > What Guix's can do, it to fix what is already there. This patch > illustrates this point. The point of authoring is a weird one when Guix can absolutely still patch the file *and* you supplied a patch that was accepted upstream. A patch, which mind you is arguably more correct than the one you've supplied for Guix, patching the build files themselves rather than generated sources. For other packages with similar issues without an upstream fix, you could on the other hand simply substitute* the .pc file. > > > Let's take 4 cases that we have here (I do not pretend to be > > > complete, of course, there are might be more levels/combinations, > > > just attempting to illustrate current case in > > > simple words/terms): > > > > > > 1. wayland compositor (weston, wlroots/sway, etc.) > > > 2. wayland client application (grim, mpv, etc. applications > > > directly interacting with wayland interfaces) > > > 3. wayland client library (qt or gtk+ in this case, also > > > directly > > > interacts with wayland to abstract it for user applications) > > > 4. user application of wayland client library (in this case > > > some > > > gtk+ based application) > > > > > > For 1 and 2, both types should have to specify wayland in > > > inputs (or propagated-inputs), and wayland-protocols in native- > > > inputs. > > Why? > One implements the protocol, the other uses it. I.e. both need > stubs generated from specification to agree. Which is not the case > for anything beyond 4. Otherwise, we would defeat whole point of > introducing abstractions. This still doesn't explain the *native*-inputs assertion. > > > One of purposes to have layer 3, is to abstract from 1 and 2. > > > i.e. when I write gtk application, as user I should not be > > > aware of where/how this application is going to run, via xorg or > > > wayland. Then why I should be aware of wayland/wayland-protocols > > > and make sure that it is provided as build input for my > > > application? > > IIUC you don't need to be aware when gtk propagates the input? > > It's similar to how you still need an Xorg server to test your GTK > > application. > From application using gtk stand point, it does not matter what is > behind gtk. As you point out, of course me, as user launching > application, I have to provide some environment which could be > either xorg or wayland. But application's source should not be > aware of that fact. This and that are different matters. Application source code continues to be blissfully unaware of the fact, but the toolchains to build your application are not. Think of it like this: When you use pkg-config (or older -config binaries), they spit out a number of compiler and linker flags to supply to gcc or ld. You as the application programmer are typically unaware of those flags and their values, especially if you turn down the verbosity of your build system, but that doesn't mean they're not supplied. > [...] > > > When cross-compiling, dependencies listed in ‘inputs’ > > > are built for the _target_ architecture; conversely, > > > dependencies listed in ‘native-inputs’ are built for > > > the architecture of the _build_ machine. > > This is the distinction to make here. "Typically used to list > > tools" here means that the package provides a tool (i.e. a binary) > > that you invoke at some point of your recipe. This can be a > > compiler like GCC, a tool to create Makefiles like automake, or an > > X server to launch tests in. The only thing in that regard when > > talking about wayland would be the wayland-scanner tool provided by > > the wayland package. > > > > Notice the contrast to what you said before with wayland being > > an input and wayland-protocols being a native one. If you need > > wayland-scanner for you build, it should be a native-input (as well > > as an input, probably). If this does become a problem later on, a > > bin/lib split for wayland might make sense. > I understand what you are saying, however as far as I am aware, > people being or not on the same page, tend to use simpler definitions > for referencing something. I was assuming that in this mailing list > we are on the same page, and free to choose to how reference things. > I suppose it would be fine to say "not runtime dependency", "build > time" or "dependency for host platform when crosscompiling" in > reference to 'native-inputs. For instance when explaining this to one > who sees Guix for the first time, I would say "run time" for 'inputs > and "build time" for 'native-inputs, not mentioning "crosscompiling" > at all on day one. > Any way, I believe it is more like philosophical subject, than > technical. I think it is important to acknowledge that people come from different backgrounds, and knowing that to do our best to curb misunderstandings. Comparing Guix' package definitions to other package managers makes it obvious as to why that is the case. Let me pick Gentoo ebuilds as an example (it's quicker to explain than whatever Debian has). There are five (as opposed to three in Guix) kinds of dependencies: - DEPEND, aka build-time dependencies, - RDEPEND, aka run-time dependencies, - BDEPEND, aka native build-time dependencies, - IDEPEND, aka native install-time dependenices, and - PDEPEND, aka what the fuck, I think I just introduced a cycle somewhere. When you say "build-time dependencies go into native inputs", someone with a shallow understanding might think that *all* build time dependencies are native inputs, when in fact only build time tools (i.e. BDEPEND in Gentoo parlance) would go there. In other systems, it might be acceptable to have a package depend on some other package without said dependency being present at build time. Consider a shell script that wraps youtube-dl. Since youtube-dl exists at some point between installation and first use, your shell script works™ whether or not youtube-dl is present at build. Some packages in Guix do work that way, though it's a pretty rare occurrence. GStreamer is one with a legitimate excuse, for example. Other than that, *all* "dependencies" (actually inputs) are present at build time, so it makes no sense to distinguish between build time and run time. Guix knows which packages it can delete from the store by tracking references. What Guix needs to distinguish is whether the package is invoked at build time (native-inputs) or whether it needs to be installed alongside the package being built (propagated-inputs) against none of the two (regular inputs). So the next time you try to explain things to a first-timer, be clear that native-inputs is for tools like compilers, linkers, code generators *invoked* at build time. It will be less confusing to learn it correctly the first time round rather than having to argue in the mailing lists when submitting some patch. I understand that keeping one piece of extra information in mind can be hard at times and the temptation to simplify is always there, but in the long term no one benefits from oversimplification. Sorry for making you read this huge wall of text and happy hacking :)