Public SourceMage Discussion List

[Thomas Orgis <thomas-forum AT orgis.org>]

Am Thu, 1 Oct 2020 02:23:16 +0200
schrieb Ismael Luceno <ismael AT iodev.co.uk>: 

> Neither distributing binaries nor having these tools compile stuff out
> of our control is acceptable.
> 
> Cargo nor "final binaries" as they call them, can freely decide
> which library versions to use.

To be clear on the terms: As I see it, the package defines its
dependencies, preferrably with version numbers (in Cargo.toml or such),
cargo fetch downloads them into $CARGO_HOME. I package that, which is
all sources.

The build then builds all the deps and then the final program, which
gets all deps linked statically.

> Also it's really unsettling the results from cdynlib and rlib in the
> system, which to me seem to have very little reason to exist.

Can you elaborate?

> There's probably a way to provide a package for each individual
> dependency installed in a global location... of course we have to
> duplicate all the effort unless we manage to automate it all.

The question is if this is practicable with the differing versions
involved. Do we dare to force certain grimoire versions of dependencies
despite the package's preference? I don't see us being able to handle
the fallout from that. Who keeps stable API if users can pick and
choose which exact version (git snapshot) they use?

Are some packages stable enough that we can provide a (or just a few)
binary version of them already installed in the system, speeding up
builds, too?

> Do we need to keep only the CARGO_TARGET_DIR or is it necessary to keep
> CARGO_HOME too?

I don't know enough about that. I guess keeping only the target is
messing with cargo internals … it's used to manage it all, after all.


Alrighty then,

Thomas