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

On 5/29/26 6:24 PM, moltonel 3x Combo wrote:

>>> On Thu, 2026-05-28 at 17:56 -0400, Eli Schwartz wrote:
>>>> cargo pretends to be a package manager
>>>> and a build system, but is neither -- only a compiler-wrapper.
> 
> I agree Cargo is barely a package manager, but it certainly is a build
> system that does more than just wrap the compiler. Is there a specific
> thing you're missing ?


I didn't say "barely". Anyways, compare the features of an actual build
system -- like autotools, cmake, meson, scons, waf, or literally
anything else, to cargo. Notice how no features of a build system are
present in cargo.

Compiling source files into an executable is not a build system -- gcc
can do that for C in a single invocation. ;)

Like cargo is capable of pipelining sources in the right order, gcc is
capable of internally calling cpp, gas, lto1, lto-wrapper, collect2,
cc1, cc1plus, ld.bfd, etc. and pipelining source files along through the
various stages of compilation, including applying feature gate flags
(that is -D) at the right stage.

>>>> "cargo install" recompiles the binary so it is not what you tested in
>>>> src_test.
> 
> That is expected and desired: tests are normally compiled with full debug,
> and you don't want the test symbols in your release build. Some other
> build systems support that too.


Clearly, rust (users?) think so. Although that's not actually true.
Compiling different feature gates for your test program compared to what
you install is not actually how normal, sane testing works.

In other languages and other build systems, the build and install of
production software is part of the same build configuration and artifact
directory that also produces unittest executables. This works in other
languages because other languages are capable of shared libraries,
whereas rust is only capable of repr(C) -- crABI seems to be roundly
ignored, who knows if we will ever get it.

But maybe I could even accept instrumented executables if they had the
same runtime documented behavior, but apparently that is too high a bar
for rust, which fails this. So, I stand by my criticism.


>>>> It does so during the src_install phase, and it (mostly?)
>>>> doesn't respect incremental builds or caching intermediate outputs.
> 
> It's doing a decent job (and slowly improving) considering the language's
> design. But in the context of an ebuild, we don't care ?


We absolutely surely care with great immensity! Did you read the email
you're replying to?

It ***matters*** to me, that src_compile, src_test, and src_install
***all*** rebuild the software from scratch, and "don't respect
incremental builds or caching intermediate outputs".

In the context of an ebuild, I should not have to build the software
twice, I shouldn't be ***executing a compiler*** during src_install (at
all -- this should be an automatic QA infraction), and I shouldn't have
to do it three times if FEATURES=test is active.

This is not about ccache comparisons, so if you somehow got that idea
then I do not know where you got it from, but please put it back again.


>>>> 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.
> 
> Yes, in the end it just copies the executables somewhere, with little
> flexibility.
> But it only cares about Rust code, it's not going to build or install man pages
> for example.


... so I am correct that it isn't doing something useful, then?


>>>> Simply require users to use doexe like for any other package without a
>>>> standard (autotools, meson, cmake etc.) build system.
> 
> Doexe would work, but cargo_src_install adds a bit of convenience: ebuild
> authors don't have to check the executable names or where they are generated.
> It's normally in target/release/$PN but some packages can get fancy, and
> https://rust-lang.github.io/rust-project-goals/2025h2/cargo-build-dir-layout.html
> could potentially complicate things.
> 
> I'm still not clear on why we want to deprecate cargo_src_insall. Is it buggy,
> or a maintenance burden ?


It is a "30 minutes longer emerge process" for the user!


>> There isn't much to gain,


We can gain 30 minutes, or perhaps an hour, of time better spent not
recompiling, resulting in user satisfaction because their emerges
complete faster.

> 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.
> 
> The differences are fairly small:
> * Default to release profile instead of dev (we surely already set that)
> * Default to use latest compatible deps (we already deny that)
> * Actually copies the executable (convenient, as stated above)
> * Maintains installation metadata (a hindrance for us, but we handle it)
> * Allows installing from web instead of local repo (we don't care about that)


Clearly it is doing something else, given it *recompiles* in src_install
because it thinks that the binary built in src_compile is out of date.

Did you read my email?


-- 
Eli Schwartz

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

wnsEABYIACMWIQTnFNnmK0TPZHnXm3qEp9ErcA0vVwUCahoYMgUDAAAAAAAKCRCEp9ErcA0vV9ue
AQC/ze62/QOEqym3bwtB/w2gbBCieNwJ+H47LqsKtYP2FwEAieJQxHlJfAC1ihd/AVlqA4JTm9SA
SdIuD4JsWK2jlwk=
=jsiE
-----END PGP SIGNATURE-----