On Fri, Jan 24, 2020 at 01:49:21PM -0800, John Soo wrote:
> Hi guix,
> 
> After working on a few rust packages, it looks like there could be another step on the process.  There are a number of libraries in the crates registry that wrap and vendor c libraries - libgit2, openssl, or jemalloc for example. The wrapping libraries, for reference, are usually called <c-library-name>-sys - libgit2-sys for example.
> 
> In the current rust-build-system, the onus of removing the vendored code falls on the ultimate consumer of the library. So, for instance, cbindgen would have to define a phase to remove the vendored code in a *-sys library even if that library is a transitive dependency.
> 
> What would you all think about adding a phase to the standard phases of the rust-build-system? I’m imagining some phase that would delete the vendored code and performed the other necessary steps to use the c libraries in /gnu/store.
> 
> Wdyt?

IMO the correct way to do it would be in the crate source that we
download. We regularly add snippets to remove vendored code, this should
be no different. The only real difference is that right now the
cargo-build-system is "too smart" and checks the #:cargo-inputs to make
sure they actually are crates before untarring them and putting them in
the guix-vendor dor. Currently the 'patch-and-rezip phase always uses xz
for compression, and crates always use gzip, so we cannot use patches or
snippets on crates. IMO the easiest way around this is to
unconditionally untar anything in #:cargo-inputs into guix-vendor/ and
continue on.

Then the only thing left is to set certain environment variables, some
of which can probably be moved to the cargo-build-system if they don't
require an actual path. LIB(GIT|SSH)2_SYS_USE_PKG_CONFIG can move,
JEMALLOC_OVERRIDE and LIBCLANG_PATH can't.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted