Re: [gentoo-dev] [PATCH] cargo.eclass: Add cargo_target_dir helper function
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 OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] questions about wxwidgets.eclass
On Sat, Jul 6, 2024 at 9:45 AM Andrey Grozin wrote: > > On Fri, 5 Jul 2024, Mike Gilbert wrote: > > It looks like you mass-filed a couple dozen bugs, but left them > > assigned to bug-wranglers. > > > > Please assign your own bug reports, especially when files en-masse. > OK, I've assigned them to the corresponding maintainers. Except 2 ones > which are maintainer-needed. To whom assign them? > > I've also filed a thacker bug https://bugs.gentoo.org/935668 to keep track > on the progress. There's a maintainer-needed@g.o bugzilla account for that. I assigned the 2 bugs you mentioned. Thanks for taking care of it!
Re: [gentoo-dev] questions about wxwidgets.eclass
On Fri, 5 Jul 2024, Mike Gilbert wrote: It looks like you mass-filed a couple dozen bugs, but left them assigned to bug-wranglers. Please assign your own bug reports, especially when files en-masse. OK, I've assigned them to the corresponding maintainers. Except 2 ones which are maintainer-needed. To whom assign them? I've also filed a thacker bug https://bugs.gentoo.org/935668 to keep track on the progress. Andrey
Re: [gentoo-dev] [PATCH] cargo.eclass: Add cargo_target_dir helper function
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 OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
