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 6E36A158041 for ; Tue, 20 Feb 2024 06:36:23 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 66E402BC0B9; Tue, 20 Feb 2024 06:35:14 +0000 (UTC) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 2E5CE2BC0B6 for ; Tue, 20 Feb 2024 06:35:14 +0000 (UTC) Received: by mail-oi1-x235.google.com with SMTP id 5614622812f47-3c15d1bd5b1so1124678b6e.1 for ; Mon, 19 Feb 2024 22:35:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708410913; x=1709015713; darn=lists.gentoo.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:from:to:cc:subject:date:message-id :reply-to; bh=iv+lyswow3lXMZ2XcYERpSE5PfrO58ZuJTlcqCVgf8Y=; b=TfI3AdXGp6MtSIOxaMSEL8wFiJkcy8ThosJct+rWBN3IjUCfKAiY/H5i87p7Bo2wmg 3mMAoRnNWEZP3EdNZlCvK74Tf7nWqCZzb9NvOZsAUPwBiryZcvOvOCgmTeerUay7BmmR FDK1PYrOwC/XVzkZiRIQz8YHmN/w3Crdn424R+u2Qm3xaoWEHVSe0M+ODnxNYxtCrZXj PGfC19A1DJI5u8ufmkOVD/oW4JR3PuKEFusMNKeJ/fCKWstxBPh7MhSd/1oVpKmQ0rHO W2qKUu/3a3XkElCDnSRl9Y84XWTdMxe/dBYldD2LzewLeMjCoI2QQNT09JxPtFbNA1Nn Sx+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708410913; x=1709015713; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=iv+lyswow3lXMZ2XcYERpSE5PfrO58ZuJTlcqCVgf8Y=; b=Cz14C8tfTffzq/ljH4n6m6k/NDMtke6hpxT9aM9/JkOwkAg5e2ZxAjgBTY6pp9PIJJ jQgKtyHB4pqqWAgbriMIbU1PIUrnaeWtaV4iM2Gx3327SfqBVnqPGaUMmXdx2VtIhINq AtcB+GezwP59Ye4ZfrMMsgikE++1DHiUM7GqwMGJ7BGaoTJdDo25blEsDtrApyvjpmmf ndwKOCHEi/EJj/Gd+0Q4fZunUIQbzi27wIJPCGKg4xrPTH2eSt697L/8UB8WhLXdOx63 VLsjZHgTWDrB3Kt4RlGaoKwcXJBfHY4bRSsHXd3D0FoQFTHibkemzg72Iasi9gNtV2kt NUtg== X-Gm-Message-State: AOJu0Yy2LIRxr2qMy/pWMEuVsy1lWba5pNwgFh3lyakzf7CwSTkVjEUB 9JU5hTVHPvA5bOjpJtCDuZYc18KxHz2nUW1Vyj8nTRUucds+sq1Bnp3gwvOC X-Google-Smtp-Source: AGHT+IHcGKQmlwmb72CjGBNKTxZXuKzwNe1nPpW3kmHdG35MjXEJ1+jZGVpjFagASIZCiVXgEXuqcA== X-Received: by 2002:a54:4090:0:b0:3bf:dc29:c2cf with SMTP id i16-20020a544090000000b003bfdc29c2cfmr13929955oii.14.1708410912660; Mon, 19 Feb 2024 22:35:12 -0800 (PST) Received: from acleverhostname.attlocal.net (108-200-163-197.lightspeed.bcvloh.sbcglobal.net. [108.200.163.197]) by smtp.gmail.com with ESMTPSA id a14-20020a05680802ce00b003c15d61ec3fsm461475oid.37.2024.02.19.22.35.11 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Feb 2024 22:35:11 -0800 (PST) From: Eli Schwartz To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] [PATCH v2 5/5] distutils-r1.eclass: fix src_configure to handle flag-o-matic correctly Date: Tue, 20 Feb 2024 01:14:45 -0500 Message-ID: <20240220063504.3959739-6-eschwartz93@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240220063504.3959739-1-eschwartz93@gmail.com> References: <1b9b73ea-9895-4680-aab7-117e47c9cc36@gmail.com> <20240220063504.3959739-1-eschwartz93@gmail.com> 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 Content-Transfer-Encoding: 8bit X-Archives-Salt: 02ab55c8-4425-4e13-99f0-ccdee7ee56a7 X-Archives-Hash: c62bc1db85a29911b42668991f019d3e Use of python_configure_all is a bit broken, because distutils-r1 is a bit broken. It has the intriguing value-claim that *FLAGS shall be modified with local -x as part of run-phase, which means that all modifications are reset as soon as any given phase exits. Including sub-phases. If you make changes in python_configure or python_configure_all, as you are expected to do instead of defining src_configure and then running the eclass phases manually, your changes inherently get erased before you actually *get* to running builds (i.e. reading the variables). For an example of how this works, consider dev-python/scipy. It builds with filter-lto, for the standard reasons. However, filter-lto gets run inside python_configure_all, so it gets erased and ignored. Note: it "worked" anyways prior to reworking meson.eclass to pass -Db_lto based on `is-flagq flto`. This is because filter-lto removed it from LDFLAGS, and since distutils-r1 doesn't localize that variable, the changes stuck around. As a result: - the previous fix to scipy caused scipy to be compiled with LTO, but not linked with LTO - meson.eclass changes caused scipy to be built with -Db_lto=true, which affects both compiling and linking It's absolutely unsafe to have flag-o-matic be ignored like this, and it is fascinating to end up with LTO restored into compile flags while still being filtered from LDFLAGS... simply as a side effect of distutils-r1 not modifying the latter. - this patch causes scipy to be built with -Db_lto=false Consequences of the change make no difference to standard dev-python/ packages, but affect packages that use both distutils-r1 and other packaging infrastructure: - global variables for tools are exported. This is supposed to be a safe, albeit unnecessary for better-than-setuptools build systems, option. - the "debug" option applies the DEBUG preprocessor macro to more than just python code. This was already the case for python projects that built non-CPython API C/C++ code and then linked them with thin python wrappers, so projects with python bindings shouldn't be any different. Also, it is a "debug" use flag so it's pretty silly if it only toggles debug on python bindings but not the rest of the package, so just... deal with it I guess? - any project that uses cython, now ignores the Modern C Porting flag "incompatible-pointer-types". This is terrible, because code which should trigger that error is terrible. But it's also terrible for python projects with mixed Cython and handwritten C, to squelch that error just because one file happens to use Cython. Yet, we do it because we don't have a way to make extremely specific files built with different CFLAGS compared to the rest of the project. There's no actual reason to treat handwritten C python modules different from non-distutils phases. Signed-off-by: Eli Schwartz --- no change eclass/distutils-r1.eclass | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass index a42adc182ed9..841fe2df5405 100644 --- a/eclass/distutils-r1.eclass +++ b/eclass/distutils-r1.eclass @@ -1815,16 +1815,15 @@ distutils-r1_run_phase() { fi # Set up build environment, bug #513664. - local -x AR=${AR} CC=${CC} CPP=${CPP} CXX=${CXX} tc-export AR CC CPP CXX if [[ ${DISTUTILS_EXT} ]]; then if [[ ${BDEPEND} == *dev-python/cython* ]] ; then # Workaround for https://github.com/cython/cython/issues/2747 (bug #918983) - local -x CFLAGS="${CFLAGS} $(test-flags-CC -Wno-error=incompatible-pointer-types)" + append-cflags $(test-flags-CC -Wno-error=incompatible-pointer-types) fi - local -x CPPFLAGS="${CPPFLAGS} $(usex debug '-UNDEBUG' '-DNDEBUG')" + append-cppflags $(usex debug '-UNDEBUG' '-DNDEBUG') # always generate .c files from .pyx files to ensure we get latest # bug fixes from Cython (this works only when setup.py is using # cythonize() but it's better than nothing) -- 2.43.0