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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id EDF34159557 for ; Wed, 3 Jul 2024 11:16:30 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B497DE2B1D; Wed, 3 Jul 2024 11:16:26 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 767B3E2B1A for ; Wed, 3 Jul 2024 11:16:26 +0000 (UTC) Message-ID: Subject: Re: [gentoo-dev] [PATCH 1/5] gui-libs/gtk: add a "poison" macro support to disable X/wayland From: Mart Raudsepp To: gentoo-dev@lists.gentoo.org, Eli Schwartz Cc: gnome@gentoo.org, xfce@gentoo.org, binhost@gentoo.org Date: Wed, 03 Jul 2024 14:16:21 +0300 In-Reply-To: <874j9f3rsq.fsf@gentoo.org> References: <20240623173646.3368935-1-eschwartz93@gmail.com> <20240623173646.3368935-2-eschwartz93@gmail.com> <877cecnkiy.fsf@gentoo.org> <173dae61-1b86-42db-9726-3c10435ec86f@gmail.com> <874j9f3rsq.fsf@gentoo.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.52.2 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 X-Archives-Salt: 06c40229-2a77-4b6b-9b58-88e9871e8d62 X-Archives-Hash: 6252f6bd84dbe8e3b05927512798e676 On Thu, 2024-06-27 at 05:58 +0100, Sam James wrote: > Eli Schwartz writes: >=20 > > On 6/26/24 5:03 AM, Sam James wrote: > > > Eli Schwartz writes: > > >=20 > > > > Many packages perform automagic dependencies on gdk's backend > > > > implementations by checking if the macro is defined and then > > > > using the > > > > code it unlocks, rather than having a buildsystem option such > > > > as > > > > -Dwayland=3Dtrue. > > > >=20 > > > Doesn't gtk3 need this too? Also, could we have an upstream > > > report > > > making them aware of this for gtk4? > >=20 > >=20 > > Yes, gtk3 needs this too (and patches in this series depend on it). > >=20 > > At https://github.com/gentoo/gentoo/pull/37259=C2=A0there are 6 patches= , > > not > > 5 -- I appear to have accidentally excluded the first patch when > > sending > > it to the list, unsure how that happened. It's almost ccompletely > > copy/paste from gtk4. >=20 > Thanks for clarifying - I was convinced I'd seen you show me it (I > probably saw it on the branch) but I didn't think to check the PR. >=20 > >=20 > > As far as reporting this upstream goes, I'm somewhat nervous they > > will > > suggest you should simply build against what you use and require > > what > > you build against. It's not a completely unreasonable suggestion, > > in > > fact it's the one I described as option 4 and Gentoo simply cannot > > use > > it today since it would require new EAPI. >=20 > I tend to agree. I see this as kind of our fault / a Gentoo-ish > problem. Please do see about approaching upstream about this in the context of GTK4 in a constructive friendly manner, perhaps from the angle of how to transition any distribution to a GTK that does not include X11 support with less migrational pain - this should be of interest for more cases than Gentoo. Maybe the idea about selecting backend stubs to include for their API functions, which would just end up returning what a fully enabled backend would return when the running environment is NOT that backend (e.g. when gdk-x11 functions are called in a wayland native app or gdk- wayland functions are called when X11 or Xwayland is in use). If that gains some traction, maybe we could also do this for GTK3 as well. Given how we'd have to end up maintaining this long term, such upstream discussions are sort of a soft blocker for proceeding with the patchset, as far as I'm concerned. Mart