Re: antioxidant-build-system can be tested as a channel, + > GTK app 'castor' builds

[Maxime Devos]

kiasoc5@disroot.org schreef op di 31-05-2022 om 17:45 [+0000]:
> Hi Maxime,
> 
> > 
> > Non-goals:
> > 
> > * Produce exactly the same binaries with exactly the same dependencies as 
> > with
> > Cargo. If you want to reproduce a binary produced with Cargo, use Cargo.
> > 
> 
> If I compile project P to produce binary A (with antioxidant) and binary C
> (with Cargo), will A and C have the same functionality?

If nothing weird is going on, yes.  Though antioxidant and Cargo have
different methods for selecting ‘features’, so a creative Rust app
author could engineer things such that when compiled with Cargo, the
app prints "hello cargo" and when compiled with antioxidant, it prints
"hello antioxidant".

I expect such situations to be the exception though, and if such a
thing happens, a $GUIX_PACKAGER could manually choose the right set of
‘features’ and put an outdated dependency in inputs/native-inputs if
needed.

That said, I haven't ‘tried out’ many of the Rust apps, mostly only
built them.

> And for dependencies not being the same, is this just limited to using the 
> latest version of crates instead of following the versions in Cargo.toml?

If you feed antioxidant-build-system the exact same versions
of dependencies as specified in Cargo, in principle you should
get something equivalent (except maybe for feature flags because
antioxidant has a different procedure for automatically selecting
feature flags, but if you really want to, you as writer of the
package definition could manually pick the features such that they
match 100% with those that Cargo would have picked).

However, the package transformation procedures in the antioxidant
channel for turning Cargo packages into antioxidant packages currently
often just select the latest version.

Greetings,
Maxime

signature.asc
Description: This is a digitally signed message part