Re: [PATCH 1/2] cargo.eclass: for EAPI 9, ban cargo_src_install

On 5/29/26 6:33 AM, Michał Górny wrote:
> On Thu, 2026-05-28 at 17:56 -0400, Eli Schwartz wrote:
>> This was always a terrible idea. cargo pretends to be a package manager
>> and a build system, but is neither -- only a compiler-wrapper.
>>
>> "cargo install" recompiles the binary so it is not what you tested in
>> src_test. It does so during the src_install phase, and it (mostly?)
>> doesn't respect incremental builds or caching intermediate outputs. It
>> also cannot install anything other than what doexe does, since cargo
>> doesn't support *building* multiple output types, let alone installing
>> them in a uniform way.
>>
>> Simply require users to use doexe like for any other package without a
>> standard (autotools, meson, cmake etc.) build system.
>>
> 
> Sorry for asking the hard question, but is there a reason we can't do it
> like with Python -- just execute 'install' immediately in compile phase?
> Having to reinvent the wheel is kinda annoying.


For python there's a good reason, as it's needed for src_test. And
installing is also "complex" as opposed to a single doexe. You need a
custom src_install anyway in most cases, to install e.g. completions.

There isn't much to gain, and on the flip side I don't really understand
what the underlying difference between cargo build and cargo install is.
Clearly they are different somehow, and my assumption is that something,
somewhere, is not properly respected by cargo install.

But I'm happy to listen to anyone who better understands the
ramifications here. I'm not pushing this patch for now (just the SRC_URI
one) until there is rough consensus that this is the best approach.

-- 
Eli Schwartz

-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQTnFNnmK0TPZHnXm3qEp9ErcA0vVwUCahmvnAUDAAAAAAAKCRCEp9ErcA0vV/eh
APwM8JNCouTndR8TAMiU0DfO7Lsm//yCjWKI4vx3dbkjSQD/WBQnlKq9R9hFEivUHUVsa+LyjrRl
pIxQ6/u1F4YgVQ0=
=y/Q0
-----END PGP SIGNATURE-----