Re: Overhauling the cargo-build-system

[Efraim Flashner <efraim@flashner.co.il>]

[-- Attachment #1: Type: text/plain, Size: 2181 bytes --]

On Sun, Nov 17, 2019 at 10:22:21PM +0100, Ludovic Courtès wrote:
> Hi,
> 
> Efraim Flashner <efraim@flashner.co.il> skribis:
> 
> > The big problems are the recursive dependencies, the partial
> > dependencies and the versioning. There are some that are easy to figure
> > out, serde always needs serde-derive, winapi always needs the
> > winapi-[i686|x86_64] crates, rayon -> rayon-core, etc.
> 
> Do you mean that the crate importer returns partial dependency info?
> That alone would be OK, many importers return incomplete dependency
> info, but we can fill that out when making the package.

It returns incomplete information. The way our packaging works it
says that it wants the latest version of a dependency, but often it's
looking for a different version.

> 
> > I suppose one way to work around some of the issues is to make it so
> > that the crates "build" by copying the source to %out/share/guix-vendor
> > or something.
> 
> So the core issue is that there’s nothing like shared libraries, is that
> correct?  This, in turn, means that there’s nothing to actually build,
> and thus a crate doesn’t really map to a package in the usual sense of
> the word, right?

We can build it and run the tests, but it's not entirely useful. I have
a blog post I'm working on, but basically if binary A wants B, and
library B wants C, D, and E, A might only want B with features from D.
So if B doesn't build because of C it doesn't prevent A from building.

Plus logistically it doesn't really work to link libraries to binaries
in the manner we're used to.

> 
> In that case, what you suggest (copying the source in the package
> output) sounds like it could work.  It would be an improvement over what
> we have now: the package graph would correspond to the crate graph.
> 

It would also make it easier to patch the sources to remove vendored C
libraries or patch Cargo.toml files.

> Thanks,
> Ludo’.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]