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

[Florian Schmaus <flow@gentoo.org>]

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