From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?utf-8?Q?Ludovic_Court=C3=A8s?= <ludo@gnu.org>
Subject: Re: Overhauling the cargo-build-system
Date: Sat, 23 Nov 2019 18:27:53 +0100
Message-ID: <87wobq33l2.fsf@gnu.org>
References: <20191010155056.GD1301@E5400> <87d0f4p6xd.fsf@gnu.org>
 <20191011141342.GC13364@E5400>
 <e2b9941a46d4d552652732d6d5f14be0@riseup.net> <87imnjtsk3.fsf@gnu.org>
 <20191117071934.GC12423@E5400> <874kz2jj02.fsf@gnu.org>
 <20191118102039.GJ15074@E5400>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Return-path: <guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:470:142:3::10]:37498)
 by lists.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <ludo@gnu.org>) id 1iYZCO-0006hb-LU
 for guix-devel@gnu.org; Sat, 23 Nov 2019 12:27:57 -0500
In-Reply-To: <20191118102039.GJ15074@E5400> (Efraim Flashner's message of
 "Mon, 18 Nov 2019 12:20:39 +0200")
List-Id: "Development of GNU Guix and the GNU System distribution."
 <guix-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/guix-devel>,
 <mailto:guix-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/guix-devel>
List-Post: <mailto:guix-devel@gnu.org>
List-Help: <mailto:guix-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/guix-devel>,
 <mailto:guix-devel-request@gnu.org?subject=subscribe>
Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org
Sender: "Guix-devel" <guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org>
To: Efraim Flashner <efraim@flashner.co.il>
Cc: guix-devel@gnu.org

Hi,

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

> On Sun, Nov 17, 2019 at 10:22:21PM +0100, Ludovic Court=C3=A8s wrote:
>> Hi,
>>=20
>> Efraim Flashner <efraim@flashner.co.il> skribis:
>>=20
>> > 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.
>>=20
>> 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 =E2=80=9Cguix import crate=E2=80=9D 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.
>>=20
>> So the core issue is that there=E2=80=99s nothing like shared libraries,=
 is that
>> correct?  This, in turn, means that there=E2=80=99s nothing to actually =
build,
>> and thus a crate doesn=E2=80=99t really map to a package in the usual se=
nse 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=E2=80=99ll wait for your blog post to see what you mean by =E2=80=9Cdoesn=
=E2=80=99t really
work=E2=80=9D.  :-)

Thanks for explaining,
Ludo=E2=80=99.