Re: Overhauling the cargo-build-system

["Ludovic Courtès" <ludo@gnu.org>]

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.

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

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.

Thanks,
Ludo’.