* [gentoo-dev] [PATCH] cargo.eclass: Add cargo_target_dir helper function @ 2024-06-13 15:03 James Le Cuirot 2024-06-13 21:32 ` Lucio Sauer ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: James Le Cuirot @ 2024-06-13 15:03 UTC (permalink / raw To: gentoo-dev; +Cc: James Le Cuirot 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. 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. Signed-off-by: James Le Cuirot <chewi@gentoo.org> --- eclass/cargo.eclass | 10 ++++++++++ 1 file changed, 10 insertions(+) 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 } +# @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=$(rust_abi) + echo "${CARGO_TARGET_DIR:-target}${abi+/}${abi}/$(usex debug debug release)" +} + # @FUNCTION: cargo_src_unpack # @DESCRIPTION: # Unpacks the package and the cargo registry. -- 2.45.1 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [gentoo-dev] [PATCH] cargo.eclass: Add cargo_target_dir helper function 2024-06-13 15:03 [gentoo-dev] [PATCH] cargo.eclass: Add cargo_target_dir helper function James Le Cuirot @ 2024-06-13 21:32 ` Lucio Sauer 2024-06-14 13:54 ` James Le Cuirot 2024-06-15 13:59 ` [gentoo-dev] [PATCH v2] " James Le Cuirot 2024-06-15 18:14 ` [gentoo-dev] [PATCH] " Florian Schmaus 2 siblings, 1 reply; 10+ messages in thread From: Lucio Sauer @ 2024-06-13 21:32 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 2168 bytes --] 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. > > 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. > > Signed-off-by: James Le Cuirot <chewi@gentoo.org> > --- > eclass/cargo.eclass | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > 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 > } > > +# @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=$(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? 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! -- Lucio Sauer > # @FUNCTION: cargo_src_unpack > # @DESCRIPTION: > # Unpacks the package and the cargo registry. > -- > 2.45.1 > > [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 618 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [gentoo-dev] [PATCH] cargo.eclass: Add cargo_target_dir helper function 2024-06-13 21:32 ` Lucio Sauer @ 2024-06-14 13:54 ` James Le Cuirot 2024-06-15 20:02 ` Lucio Sauer 0 siblings, 1 reply; 10+ messages in thread From: James Le Cuirot @ 2024-06-14 13:54 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 4118 bytes --] 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. > > > > 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. > > > > Signed-off-by: James Le Cuirot <chewi@gentoo.org> > > --- > > eclass/cargo.eclass | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > 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 > > } > > > > +# @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=$(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? > > 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! I did consider that, but for the sake of simplicity, I think I'd prefer just overriding CHOST when you need to do this. There are already similar examples of this. 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? Perhaps the runner respects CARGO_BUILD_TARGET? 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 case any rebuilding occurs. It could also be used for other custom scenarios like this one. What do you think? diff --git a/app-misc/anki/anki-24.04.1.ebuild b/app-misc/anki/anki-24.04.1.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 - cargo build --release --package runner || die + tc-env_build cargo_src_compile --package runner if use gui; then - out/rust/release/runner build -- $(get_NINJAOPTS) wheels || die + cargo_env "$(CHOST=${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 for runner in pytest rust_test jest; do - out/rust/release/runner build -- $(get_NINJAOPTS) check:$runner || \ + cargo_env "$(CHOST=${CBUILD} cargo_target_dir)/runner" build -- $(get_NINJAOPTS) check:$runner || \ die "check:$runner failed!" done } [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 858 bytes --] ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [gentoo-dev] [PATCH] cargo.eclass: Add cargo_target_dir helper function 2024-06-14 13:54 ` James Le Cuirot @ 2024-06-15 20:02 ` Lucio Sauer 0 siblings, 0 replies; 10+ messages in thread From: Lucio Sauer @ 2024-06-15 20:02 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 5102 bytes --] 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. > > > > > > 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. > > > > > > Signed-off-by: James Le Cuirot <chewi@gentoo.org> > > > --- > > > eclass/cargo.eclass | 10 ++++++++++ > > > 1 file changed, 10 insertions(+) > > > > > > 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 > > > } > > > > > > +# @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=$(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? > > > > 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! > > I did consider that, but for the sake of simplicity, I think I'd prefer just > overriding CHOST when you need to do this. There are already similar examples > of this. > > 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="$(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 case 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? > > diff --git a/app-misc/anki/anki-24.04.1.ebuild b/app-misc/anki/anki-24.04.1.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 > > - 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. -- Lucio Sauer > if use gui; then > - out/rust/release/runner build -- $(get_NINJAOPTS) wheels || die > + cargo_env "$(CHOST=${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 > > for runner in pytest rust_test jest; do > - out/rust/release/runner build -- $(get_NINJAOPTS) check:$runner || \ > + cargo_env "$(CHOST=${CBUILD} cargo_target_dir)/runner" build -- $(get_NINJAOPTS) check:$runner || \ > die "check:$runner failed!" > done > } [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 618 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* [gentoo-dev] [PATCH v2] cargo.eclass: Add cargo_target_dir helper function 2024-06-13 15:03 [gentoo-dev] [PATCH] cargo.eclass: Add cargo_target_dir helper function James Le Cuirot 2024-06-13 21:32 ` Lucio Sauer @ 2024-06-15 13:59 ` James Le Cuirot 2024-06-15 18:14 ` [gentoo-dev] [PATCH] " Florian Schmaus 2 siblings, 0 replies; 10+ messages in thread From: James Le Cuirot @ 2024-06-15 13:59 UTC (permalink / raw To: gentoo-dev; +Cc: James Le Cuirot 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. 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. Signed-off-by: James Le Cuirot <chewi@gentoo.org> --- eclass/cargo.eclass | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass index 40d98211ce7f9..7463e1a0a600a 100644 --- a/eclass/cargo.eclass +++ b/eclass/cargo.eclass @@ -319,6 +319,16 @@ _cargo_gen_git_config() { fi } +# @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=/$(rust_abi) + echo "${CARGO_TARGET_DIR:-target}${abi}/$(usex debug debug release)" +} + # @FUNCTION: cargo_src_unpack # @DESCRIPTION: # Unpacks the package and the cargo registry. -- 2.45.1 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [gentoo-dev] [PATCH] cargo.eclass: Add cargo_target_dir helper function 2024-06-13 15:03 [gentoo-dev] [PATCH] cargo.eclass: Add cargo_target_dir helper function James Le Cuirot 2024-06-13 21:32 ` Lucio Sauer 2024-06-15 13:59 ` [gentoo-dev] [PATCH v2] " James Le Cuirot @ 2024-06-15 18:14 ` Florian Schmaus 2024-06-15 21:56 ` Ionen Wolkens 2 siblings, 1 reply; 10+ messages in thread From: Florian Schmaus @ 2024-06-15 18:14 UTC (permalink / raw To: gentoo-dev, James Le Cuirot [-- Attachment #1.1.1: Type: text/plain, Size: 917 bytes --] On 13/06/2024 17.03, 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. Glad that someone is working on better cross-compilation support for rust. :) That said, many rust ebuilds generate shell completions by invoking the just compiled binary in src_install(). This does not work out of the box when cross-compiling. Is there anything we can or should do about it (besides binfmt_misc)? For example, asking the according projects to implement a mechanism to extract the completions files from the binary without running it, or have the build system generate the completion files as result of the build? - Flow [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 17797 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 618 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [gentoo-dev] [PATCH] cargo.eclass: Add cargo_target_dir helper function 2024-06-15 18:14 ` [gentoo-dev] [PATCH] " Florian Schmaus @ 2024-06-15 21:56 ` Ionen Wolkens 2024-06-15 22:22 ` James Le Cuirot 0 siblings, 1 reply; 10+ messages in thread From: Ionen Wolkens @ 2024-06-15 21:56 UTC (permalink / raw To: gentoo-dev; +Cc: James Le Cuirot [-- Attachment #1: Type: text/plain, Size: 1891 bytes --] On Sat, Jun 15, 2024 at 08:14:34PM +0200, Florian Schmaus wrote: > On 13/06/2024 17.03, 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. > > Glad that someone is working on better cross-compilation support for > rust. :) > > That said, many rust ebuilds generate shell completions by invoking the > just compiled binary in src_install(). This does not work out of the box > when cross-compiling. > > Is there anything we can or should do about it (besides binfmt_misc)? > For example, asking the according projects to implement a mechanism to > extract the completions files from the binary without running it, or > have the build system generate the completion files as result of the build? All I can think of without changing entirely how they're generated is: 1. (worst) either make a 2nd build using CBUILD (yeah no), or BDEPEND on same-version self with a USE only when cross compiling 2. (lazy) skip completions w/ ewarn if tc-is-cross-compiler, just so it at least won't break cross over completion files that the user may not even care much about 3. generate them yourself with each releases and ship in a tarball, works out for users but extra burden for maintainer over little 4. ask upstream to provide proper release tarballs if not already and include pre-generated completions/docs/etc... so it's otherwise only a problem with arbitrary git checkouts (3+4 may possibly be more complicated if cargo features / USE change cli options and thus completion files) For one of my ebuilds I went with better-than-nothing #2. -- ionen [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [gentoo-dev] [PATCH] cargo.eclass: Add cargo_target_dir helper function 2024-06-15 21:56 ` Ionen Wolkens @ 2024-06-15 22:22 ` James Le Cuirot 2024-07-06 9:04 ` Florian Schmaus 0 siblings, 1 reply; 10+ messages in thread From: James Le Cuirot @ 2024-06-15 22:22 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 3433 bytes --] On Sat, 2024-06-15 at 17:56 -0400, Ionen Wolkens wrote: > On Sat, Jun 15, 2024 at 08:14:34PM +0200, Florian Schmaus wrote: > > On 13/06/2024 17.03, 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. > > > > Glad that someone is working on better cross-compilation support for > > rust. :) > > > > That said, many rust ebuilds generate shell completions by invoking the > > just compiled binary in src_install(). This does not work out of the box > > when cross-compiling. > > > > Is there anything we can or should do about it (besides binfmt_misc)? > > For example, asking the according projects to implement a mechanism to > > extract the completions files from the binary without running it, or > > have the build system generate the completion files as result of the build? > > All I can think of without changing entirely how they're generated is: > 1. (worst) either make a 2nd build using CBUILD (yeah no), or BDEPEND > on same-version self with a USE only when cross compiling > 2. (lazy) skip completions w/ ewarn if tc-is-cross-compiler, just so > it at least won't break cross over completion files that the user > may not even care much about > 3. generate them yourself with each releases and ship in a tarball, > works out for users but extra burden for maintainer over little > 4. ask upstream to provide proper release tarballs if not already and > include pre-generated completions/docs/etc... so it's otherwise > only a problem with arbitrary git checkouts > (3+4 may possibly be more complicated if cargo features / USE change > cli options and thus completion files) > > For one of my ebuilds I went with better-than-nothing #2. I've been doing this work for Flatcar, which doesn't use any of the packages affected by this, but it does still concern me a little. Unfortunately, none of the options are great. I've seen #2 in one or two cases, and thanks for doing that. For #1, the BDEPEND approach isn't possible with current Portage/PMS. The experimental EAPI 5-hdepend, which led to BDEPEND in EAPI 7, had a USE flag called targetroot (terrible name!) for this purpose. It wasn't based on cross-compiling, because Portage/PMS don't actually have any concept of that. It applied when ROOT!=/. We decided not to keep it though. Chances are that / won't already have an identical or at least compatible version already installed. Doing another temporary build was therefore deemed preferable. On the plus side, that's quite easy with Cargo. On the minus side, almost all Rust builds take ages. It hardly seems worth it for shell completions. I really don't see #4 happening, given that most end-user applications are normally installed using cargo install. Regarding binfmt_misc, you could explicitly invoke via qemu-user instead, making it less dependent on a particular setup. I have hacked together some helpers to do stuff like this because we really need it for Perl. In Perl's case, it would be mandatory when cross-compiling because there's really no other way. I wouldn't want it to be mandatory in this case though. [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 858 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [gentoo-dev] [PATCH] cargo.eclass: Add cargo_target_dir helper function 2024-06-15 22:22 ` James Le Cuirot @ 2024-07-06 9:04 ` Florian Schmaus 2024-07-07 3:36 ` Eli Schwartz 0 siblings, 1 reply; 10+ messages in thread From: Florian Schmaus @ 2024-07-06 9:04 UTC (permalink / raw To: gentoo-dev, James Le Cuirot, Ionen Wolkens [-- Attachment #1.1.1: Type: text/plain, Size: 2721 bytes --] On 16/06/2024 00.22, James Le Cuirot wrote: > On Sat, 2024-06-15 at 17:56 -0400, Ionen Wolkens wrote: >> On Sat, Jun 15, 2024 at 08:14:34PM +0200, Florian Schmaus wrote: >>> On 13/06/2024 17.03, 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. >>> >>> Glad that someone is working on better cross-compilation support for >>> rust. :) >>> >>> That said, many rust ebuilds generate shell completions by invoking the >>> just compiled binary in src_install(). This does not work out of the box >>> when cross-compiling. >>> >>> Is there anything we can or should do about it (besides binfmt_misc)? >>> For example, asking the according projects to implement a mechanism to >>> extract the completions files from the binary without running it, or >>> have the build system generate the completion files as result of the build? >> >> All I can think of without changing entirely how they're generated is: >> 1. (worst) either make a 2nd build using CBUILD (yeah no), or BDEPEND >> on same-version self with a USE only when cross compiling >> 2. (lazy) skip completions w/ ewarn if tc-is-cross-compiler, just so >> it at least won't break cross over completion files that the user >> may not even care much about >> 3. generate them yourself with each releases and ship in a tarball, >> works out for users but extra burden for maintainer over little >> 4. ask upstream to provide proper release tarballs if not already and >> include pre-generated completions/docs/etc... so it's otherwise >> only a problem with arbitrary git checkouts >> (3+4 may possibly be more complicated if cargo features / USE change >> cli options and thus completion files) >> >> For one of my ebuilds I went with better-than-nothing #2. > > I've been doing this work for Flatcar, which doesn't use any of the packages > affected by this, but it does still concern me a little. Unfortunately, none > of the options are great. > > I've seen #2 in one or two cases, and thanks for doing that. FYI, it turns out that at least clap-rs has support to generate the completion files as part of the build process: https://docs.rs/clap_complete/latest/clap_complete/generator/fn.generate_to.html Maybe we could encourage projects to simply adjust their build.rs to generate the completion files. This would avoid inconsistent (Gentoo) package contents when cross compiling. - Flow [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 21567 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 618 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [gentoo-dev] [PATCH] cargo.eclass: Add cargo_target_dir helper function 2024-07-06 9:04 ` Florian Schmaus @ 2024-07-07 3:36 ` Eli Schwartz 0 siblings, 0 replies; 10+ messages in thread From: Eli Schwartz @ 2024-07-07 3:36 UTC (permalink / raw To: gentoo-dev [-- Attachment #1.1: Type: text/plain, Size: 1463 bytes --] On 7/6/24 5:04 AM, Florian Schmaus wrote: > FYI, it turns out that at least clap-rs has support to generate the > completion files as part of the build process: > > https://docs.rs/clap_complete/latest/clap_complete/generator/fn.generate_to.html > > Maybe we could encourage projects to simply adjust their build.rs to > generate the completion files. This would avoid inconsistent (Gentoo) > package contents when cross compiling. Cargo is NOT a real build system, as partially evidenced by the fact that it does not possess an install system either. build.rs is an extremely crude hack around this and doesn't work well for that use case. The main consequence is that you have to manually find a checksummed build artifact, since that's all build.rs can create. It reduces the temptation of projects to support this at all, in favor of just providing an argument to generate it which they figure is the only thing people can practically use. So, you can try to convince upstreams to care, but I am cynical. ripgrep, which I suspect due to recent conversations is the reason you're mentioning this, *used* to do exactly what you suggest. Recent versions have moved on to rolling their own argument parser and manpage generator, which they then use to produce prebuilt binary packages via, well, running the compiled binary with --generate. I get the feeling they aren't worried about cross compiling. -- Eli Schwartz [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 236 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2024-07-07 3:36 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-06-13 15:03 [gentoo-dev] [PATCH] cargo.eclass: Add cargo_target_dir helper function James Le Cuirot 2024-06-13 21:32 ` Lucio Sauer 2024-06-14 13:54 ` James Le Cuirot 2024-06-15 20:02 ` Lucio Sauer 2024-06-15 13:59 ` [gentoo-dev] [PATCH v2] " James Le Cuirot 2024-06-15 18:14 ` [gentoo-dev] [PATCH] " Florian Schmaus 2024-06-15 21:56 ` Ionen Wolkens 2024-06-15 22:22 ` James Le Cuirot 2024-07-06 9:04 ` Florian Schmaus 2024-07-07 3:36 ` Eli Schwartz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox