Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] How to handle the rust ecosystem with offline builds

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Ismael Luceno <ismael AT iodev.co.uk>
  • To: Thomas Orgis <thomas-forum AT orgis.org>
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] How to handle the rust ecosystem with offline builds
  • Date: Thu, 1 Oct 2020 02:23:16 +0200

On 30/Sep/2020 12:54, Thomas Orgis wrote:
> Hi all,
>
> I just pushed a commit that enables an offline build of cbindgen. This
> is right now the only spell in the rust-crates section, so it is a good
> time to discuss the questions its existence raises.
>
> I quote myself and hereby ask for some discussion and perhaps some
> executive decision regarding upload place for the cache tarballs or
> whatnot.
>
> I hope the main point of spells downloading things during BUILD being
> unacceptable is uncontested.
>
> commit 7648fe210d095397484dc911330360c238ce2bb6 (HEAD -> master,
> origin/master, origin/HEAD)
> Author: Thomas Orgis <sobukus AT sourcemage.org>
> Date: Wed Sep 30 12:15:55 2020 +0200
>
> cbindgen: make build local and reproducible
>
> My approach involves a cargo snapshot tarball (directory .cargo,
> matching the default $HOME/.cargo, also less chance of conflict
> in source trees) that is extracted inside the source tree and
> used by the default build.
>
> It's still WIP. We need to agree on the idea of cargo snapshots
> or another way of integrating the cargo downloads into summon.
> In my opinion, we need something that can be mirrored/self-hosted.
>
> I hope we find something better in future. Maybe at least some
> tooling support in quill to generate those cargo snapshots
> automatically. But one crucial point: Each grimoire guru needs
> access to a place that serves as canonical URL. I use my own
> server at sobukus.de now, but I presume it should be on
> sourcemage.org …

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.

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.

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.

I'm inclined to do that instead.

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


> Also, about the naming of spells: With the increasing number of
> ecosystems (perl, python[23], ruby, go, rust) that produce their
> inevitable re-inventions of various wheels in form of packages,
> we really should start prefixing things. The spell cbindgen should
> be called rust-cbindgen. Anything from CPAN should be perl-anything
> or cpan-anything.

+1.




Archive powered by MHonArc 2.6.24.

Top of Page