Re: [gentoo-dev] [PATCH] cargo.eclass: Add cargo_target_dir helper function

[Florian Schmaus]

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.

https://docs.rs/clap_complete/latest/clap_complete/generator/fn.generate_to.html



- Flow

FYI, it turns out that at least clap-rs has support to generate the completion files as part of the build process: 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.

OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature