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

[James Le Cuirot <chewi@gentoo.org>]

[-- 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 --]