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 9BB2915817D for ; Sat, 15 Jun 2024 20:02:38 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 136BFE2B89; Sat, 15 Jun 2024 20:02:23 +0000 (UTC) Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.66]) (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 A41CBE2AD0 for ; Sat, 15 Jun 2024 20:02:22 +0000 (UTC) Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 55E8A240101 for ; Sat, 15 Jun 2024 22:02:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1718481740; bh=+NMsN3N6IU4UTk/N5v9oUZRnIIhdcOx8PjQWPu7HHWE=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition:From; b=U4g1htXLxtS5PDD10KlrZfvNqtp6C00YVXsIMYvfL8IeBgkHlookYw0A0qTPNh6eF vEpP1hDWWvoyBwjrlRFruJOwHSlMV1ArVFUDAsqLGfazV4x4pHeJZiGgOA94Xy6gwe aIxG369OjIpO+LqJ2Zb54X2fG44+7mBuN3AEfpVFUK8WB+hlrEVJNa+uVRWzLen27q 28d46BIZV2AsewuRmHW2jNcm7EtJfcUW2zvU/Ww1VEpVgF3Ye/G/sV1obpptf/5vLy 6S48gD7JZvSsIHaOX7S/is3AjEOVlzA+KpS3kb8+ZvPEbdhAELAB+FxyLiOSHiuI+8 GXUiWLyx8vnCg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4W1n9k4cYYz9rxG for ; Sat, 15 Jun 2024 22:02:18 +0200 (CEST) Date: Sat, 15 Jun 2024 20:02:14 +0000 From: Lucio Sauer To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [PATCH] cargo.eclass: Add cargo_target_dir helper function Message-ID: References: <20240613150530.24679-1-chewi@gentoo.org> <7afchawnwsvh54fkyedgu727xddihslxk44tjbmtiobr5llmph@rzoy2fteogxc> 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-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kmv3h44rkbpijzad" Content-Disposition: inline In-Reply-To: X-Archives-Salt: f162a116-b9fd-4957-bf31-09880eaab128 X-Archives-Hash: f91d451f8e76a1b82bddef025d7792e3 --kmv3h44rkbpijzad Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 14, 2024 at 02:54:47PM +0100, James Le Cuirot wrote: > On Thu, 2024-06-13 at 21:32 +0000, Lucio Sauer wrote: > > On Thu, Jun 13, 2024 at 04:03:44PM +0100, James Le Cuirot wrote: > > > Several Cargo-based ebuilds cannot use cargo_src_install for various > > > reasons and manually install binaries from within the target directory > > > instead. It is common to see `target/$(usex debug debug release)`, but > > > this lacks the target ABI when cross-compiling, so provide a helper > > > function. > > >=20 > > > There are some multilib Cargo-based ebuilds that always set the target > > > ABI, even when not cross-compiling. It would be simpler to do this in > > > general, so once ebuilds have been updated to use this new helper, I > > > might change the eclass again accordingly. > > >=20 > > > Signed-off-by: James Le Cuirot > > > --- > > > eclass/cargo.eclass | 10 ++++++++++ > > > 1 file changed, 10 insertions(+) > > >=20 > > > diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass > > > index 40d98211ce7f9..2036fb635d569 100644 > > > --- a/eclass/cargo.eclass > > > +++ b/eclass/cargo.eclass > > > @@ -319,6 +319,16 @@ _cargo_gen_git_config() { > > > fi > > > } > > > =20 > > > +# @FUNCTION: cargo_target_dir > > > +# @DESCRIPTION: > > > +# Return the directory within target that contains the build, e.g. > > > +# target/aarch64-unknown-linux-gnu/release. > > > +cargo_target_dir() { > > > + local abi > > > + tc-is-cross-compiler && abi=3D$(rust_abi) > > > + echo "${CARGO_TARGET_DIR:-target}${abi+/}${abi}/$(usex debug debug = release)" > > > +} > > > + > > How about giving this function an optional parameter that gets passed to > > rust_abi so that you can get the build directory for targets other than > > CHOST? > >=20 > > What initially motivated this suggestion is a quirk in app-misc/anki's > > build system together with your recent change to cargo.eclass 375da3684, > > which enables cross-compilation by setting environment variables. > > Here, I first build the 'build system runner' for CBUILD, which then > > compiles the actual package for CHOST. I think I can avoid explicitly > > setting --target $(rust ${CBUILD}) for the runner for now, but it would > > be handy to easily get the build directory for CBUILD in the future! >=20 > I did consider that, but for the sake of simplicity, I think I'd prefer j= ust > overriding CHOST when you need to do this. There are already similar exam= ples > of this. >=20 > I had a look at app-misc/anki. I think you do need to give --target to the > runner right now if that's building something, otherwise how would it know > what the target is? Cargo builds for the "host architecture" (CBUILD, right?) if no target is supplied. Since I currently compile the runner before ever calling cargo_src_compile, CARGO_BUILD_TARGET=3D"$(rust_abi) has not been exported yet and Cargo falls back to compiling for CBUILD. Because this is not future-proof and my current approach is lacking, I'll switch to cargo_src_compile with the upcoming PR. > Perhaps the runner respects CARGO_BUILD_TARGET? Yes, it does. > If so, I > was thinking of making a cargo_env wrapper helper that would set that and > other variables in the context of the given command. This would be used in > cargo_src_compile, as well as cargo_src_install and cargo_src_test in cas= e any > rebuilding occurs. It could also be used for other custom scenarios like = this > one. What do you think? Sounds like a good idea. Ebuild writers will be able to specify the platform that cargo_env is supposed to set environment variables for, right? >=20 > diff --git a/app-misc/anki/anki-24.04.1.ebuild b/app-misc/anki/anki-24.04= =2E1.ebuild > index 54dfbf94f31b2..2764659ccbf51 100644 > --- a/app-misc/anki/anki-24.04.1.ebuild > +++ b/app-misc/anki/anki-24.04.1.ebuild > @@ -871,9 +871,9 @@ src_compile() { > # * generate the ninja file and run ninja afterwards > # * create the Python wheel files in "${S}"/out/wheels > =20 > - cargo build --release --package runner || die > + tc-env_build cargo_src_compile --package runner Thank you for bringing this to my attention. I forgot that I need to set cross vars for cc-rs for the runner to compile in a cross-compilation scenario. --=20 Lucio Sauer > if use gui; then > - out/rust/release/runner build -- $(get_NINJAOPTS) wheels = || die > + cargo_env "$(CHOST=3D${CBUILD} cargo_target_dir)/runner" = build -- $(get_NINJAOPTS) wheels || die > else > cargo_src_compile --package anki-sync-server > fi > @@ -901,7 +901,7 @@ src_test() { > "${S}"/build/ninja_gen/src/cargo.rs || die > =20 > for runner in pytest rust_test jest; do > - out/rust/release/runner build -- $(get_NINJAOPTS) check:$= runner || \ > + cargo_env "$(CHOST=3D${CBUILD} cargo_target_dir)/runner" = build -- $(get_NINJAOPTS) check:$runner || \ > die "check:$runner failed!" > done > } --kmv3h44rkbpijzad Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEElFlueg0TS/aEyc5qVWii3aYMopcFAmZt80NfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk0 NTk2RTdBMEQxMzRCRjY4NEM5Q0U2QTU1NjhBMkREQTYwQ0EyOTcACgkQVWii3aYM opeo9QgAukowBzmHG6oVDhmxrFUBHLRJHEXGo/edi6Xy9CJgoZ+EsJHrAUeCrPvn LvBRBa5Nk78+ctxpSOXaUwQ2L7OsiCtSf/Bg9cPD17x1Hw51rnBbfki0JibWmxyn WvOFlA/5sCLxKQixKrcsK4xNr4fxtAXYfyDaN5SXVcoW6N1m4p1e77SvchKtSmZG rOUYb7VocxBw2lOSnBrA9VdwwoBTQsRFx6y/bHVDOXaQsgxg79JPQK1Gp084PaJp SvWzgGoVjsi0G6WNIwpCQtGLB9nOgFjUpENoE7EW8UbGtj174YJLbG8XKakr8sVi 3VelTRqYI5Q0CuD+iJqTSpL03uYxig== =reYu -----END PGP SIGNATURE----- --kmv3h44rkbpijzad--