[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Overhauling the cargo-build-system
From: |
Efraim Flashner |
Subject: |
Re: Overhauling the cargo-build-system |
Date: |
Mon, 18 Nov 2019 12:20:39 +0200 |
User-agent: |
Mutt/1.12.2 (2019-09-21) |
On Sun, Nov 17, 2019 at 10:22:21PM +0100, Ludovic Courtès wrote:
> Hi,
>
> Efraim Flashner <address@hidden> 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 <address@hidden> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature