Re: Overhauling the cargo-build-system

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

Hi,

Efraim Flashner <efraim@flashner.co.il> skribis:

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

Maybe we can fix “guix import crate” then, because the info provided by
the HTTP API is rather detailed (see (guix import crate), which exposes
some of that as Scheme records).

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

Hmm!

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

I’ll wait for your blog post to see what you mean by “doesn’t really
work”.  :-)

Thanks for explaining,
Ludo’.