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

On Fri, 29 May 2026 at 23:51, Eli Schwartz <[email protected]> wrote:
> Notice how no features of a build system are present in cargo.

Not going to engage into a motivated no-true-scotsman argument.

> 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.

IMHO cargo does the right thing here. So call me insane, but I assure you I've
seen that particular insanity in a lot of projects, it's not a Rust
exclusive. There
are good technical reasons to not want your test executable to be the same as
your release one.

> 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.

Leaving src_test aside (as explained above, and no amount of ebuild tweaking
will change such a language fundamental).

I agree that there shouldn't be any recompilation between src_compile
and src_install,
and that something is wrong with the ebuild otherwise. But I don't
think avoiding
`cargo install` in favor of doexec is the right fix, `cargo install`
is perfectly able to reuse
the artifacts from a `cargo build`.

I have never seen the rebuilds you are talking about. Can you point at
a particular ebuild
or bug number ? It'd help understand the problem and get a proper fix.

> 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.

I think I got confused when you talked about incremental builds, which
to me is about fast
recompile after changing a line of code, and not something an ebuild
should care about.
Also, in my experience cargo should be good at reusing intermediate
artifacts between ebuild
phases, adding to the confusion.

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

???? Have fun reimplementing what cargo does in a different build system.

> > 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!

Again, if src_install recompiles stuff from src_compile, it's a bug.
But it's not something
inherently caused by `cargo install`. If something in the cargo eclass
is buggy, let's
fix it. But it would be a pity to lose the convenience of cargo_src_install.

> 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.

Again, can you reference a specific ebuild with the issue ?

> Did you read my email?

I read the whole thread, but you only clearly stated the issue of
rebuild between
src_compile and src_install in your last email. I only read that one thread,
apologies if I missed previous discussions.

-- 
Vincent de Phily