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: Sun, 17 Nov 2019 22:22:21 +0100
Message-ID: <874kz2jj02.fsf@gnu.org>
References: <20191010155056.GD1301@E5400> <87d0f4p6xd.fsf@gnu.org>
 <20191011141342.GC13364@E5400>
 <e2b9941a46d4d552652732d6d5f14be0@riseup.net> <87imnjtsk3.fsf@gnu.org>
 <20191117071934.GC12423@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]:37766)
 by lists.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <ludo@gnu.org>) id 1iWS02-0002Iw-3C
 for guix-devel@gnu.org; Sun, 17 Nov 2019 16:22:27 -0500
In-Reply-To: <20191117071934.GC12423@E5400> (Efraim Flashner's message of
 "Sun, 17 Nov 2019 09:19:34 +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:

> 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=E2=80=99s nothing like shared libraries, is=
 that
correct?  This, in turn, means that there=E2=80=99s nothing to actually bui=
ld,
and thus a crate doesn=E2=80=99t 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=E2=80=99.