From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id MIr+HriOGV9UPwAA0tVLHw (envelope-from ) for ; Thu, 23 Jul 2020 13:20:56 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id qAfqGriOGV9aYAAA1q6Kng (envelope-from ) for ; Thu, 23 Jul 2020 13:20:56 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 40BE19403C5 for ; Thu, 23 Jul 2020 13:20:56 +0000 (UTC) Received: from localhost ([::1]:33282 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jyb9b-0007FM-8F for larch@yhetil.org; Thu, 23 Jul 2020 09:20:55 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50744) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jyb9O-0007F9-Q2 for guix-devel@gnu.org; Thu, 23 Jul 2020 09:20:42 -0400 Received: from pat.zlotemysli.pl ([37.59.186.212]:33520) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jyb9L-0004Fc-Ju for guix-devel@gnu.org; Thu, 23 Jul 2020 09:20:42 -0400 Received: (qmail 12738 invoked by uid 1009); 23 Jul 2020 15:20:38 +0200 Received: from user-94-254-202-205.play-internet.pl (kuba@kadziolka.net@user-94-254-202-205.play-internet.pl) by pat.zlotemysli.pl (envelope-from , uid 1002) with qmail-scanner-2.08st (clamdscan: 0.98.6/25881. spamassassin: 3.4.0. perlscan: 2.08st. Clear:RC:1(94.254.202.205):. Processed in 0.057509 secs); 23 Jul 2020 13:20:38 -0000 Received: from user-94-254-202-205.play-internet.pl (HELO gravity) (kuba@kadziolka.net@94.254.202.205) by pat.zlotemysli.pl with SMTP; 23 Jul 2020 15:20:37 +0200 Date: Thu, 23 Jul 2020 15:20:36 +0200 From: Jakub =?utf-8?B?S8SFZHppb8WCa2E=?= To: guix-devel@gnu.org Subject: The rust:cargo output - why? Message-ID: <20200723132036.xxuy63acwe3dji7p@gravity> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="a7fl2ggwtvkk5k5s" Content-Disposition: inline Received-SPF: none client-ip=37.59.186.212; envelope-from=kuba@kadziolka.net; helo=pat.zlotemysli.pl X-detected-operating-system: by eggs.gnu.org: First seen = 2020/07/23 09:20:38 X-ACL-Warn: Detected OS = Linux 3.11 and newer X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Spam-Score: -1.61 X-TUID: k8oegJoE/hLt --a7fl2ggwtvkk5k5s Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Guix, I have noticed that the procedure we use to install cargo to a separate output in the Rust definition has started rebuilding quite a large part of the compiler when the prefix is changed starting in Rust 1.34. I have asked around, and upstream doesn't support any straightforward way of installing cargo to a separate prefix: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Inst= alling.20cargo.20with.20a.20different.20prefix I have some hacks in mind that could allow us to keep installing cargo into a separate output without the extra rebuild, such as building the compiler with --keep-stage or installing cargo with a DESTDIR and manually moving the files. However, none of these, including the current solution, are without tradeoffs. This makes me wonder - why not put cargo in :out? In my experience with using Rust, cargo is an integral part of the toolchain and I find it quite unlikely that anyone would find bare rustc useful. Indeed, rust is depended upon explicitly by cargo-build-system, icecat and icedove, and all of these also use the cargo output. User-facing usage is even more likely to use cargo. As such, I would like to suggest that we merge rust:out and rust:cargo on staging. `guix size rust rust:cargo` reports that the closure would increase from 600 to 700 MiB. Thoughts? Regards, Jakub K=C4=85dzio=C5=82ka --a7fl2ggwtvkk5k5s Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE5Xa/ss9usT31cTO54xWnWEYTFWQFAl8ZjqQACgkQ4xWnWEYT FWQucQ//RlqItxJzXMH7aH+RdXEtttpQGFLFThT/eddBNN82IZjgxQHrwop2KkOH wSzfEOvSpMqQllzG6JPY2Fw6q6vsYcIU3/z1TAKRrSsgGvouRBzv4b4gc8XHAytr 4SakR9BTUUyDEXNgnfzwQCaaWpyK7Mk046lLPeYZRiuoFn7sy8Sl3NKXFlTw//nw Edg6YN++7ZEgIiRUlF1KEKTmot5sVE/1GVmaJmsYs5MPoZEped9VtECZNdGy1XoA 6DVQrgXDSE44hZU0ZB3VydG1F3U0Tr6oCyHsjTFefiVsmdpGAlsTJK80aZBHyDaj QM6ejoPUsHETaunojIy2DWpFDhx+owkJhE0xlf75HH3iotnC6a/h+MlIEPA1xJ7h IIudjw+LEZRSJT6rqGUnmAkNBGgDPJWFXG7tXXoRwd5bW9JPZAugoDDmSxMqcgho hU1DQlfZRAWSBXQEKg9mpHtD+HDXXUA0Kb9mWzJZN/LaMLGML1AzEzDeZ5OLAHtU IEdV36csVXRR64EWvJ+teE2Ws4fHsOTVnewmj865q0nK0knAK8KYiJlkbZqWHJmb D9jI82jIr3XTXyqsvkeFOvhiyP8BBaKmmczNGmRftquW8LzHisdwpqRyxKAgCXjh WN5grS5LeSb+HvGP02z0xFOl7eOeeDPXbeUa6CkA+6VibpA625U= =Gd9p -----END PGP SIGNATURE----- --a7fl2ggwtvkk5k5s--