unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: "Jakub Kądziołka" <kuba@kadziolka.net>
To: Efraim Flashner <efraim@flashner.co.il>
Cc: 42049@debbugs.gnu.org
Subject: [bug#42049] [PATCH 0/4] build-system/cargo: Propagations across the crate closure.
Date: Thu, 13 Aug 2020 18:16:38 +0200	[thread overview]
Message-ID: <20200813161638.ffgfusjplz5zcfgx@gravity> (raw)
In-Reply-To: <20200813094843.GC1228@E5400>

[-- Attachment #1: Type: text/plain, Size: 1261 bytes --]

On Thu, Aug 13, 2020 at 12:48:43PM +0300, Efraim Flashner wrote:
> I'm going to respond here so the thoughts don't get lost. While it would
> take care of some of the issues we have regarding adding regular inputs
> or propagated-/native- inputs, I don't think this is the way we want to
> go. If we can't figure out how to re-use build artifacts then I'd rather
> copy the go-build-system and install the sources into the output and use
> that as the input for the next package. That would give us the
> build-graph which we really want.

Note that this wouldn't solve all the issues, we would still need
an equivalent for propagated phases, to set any environment variables
necessary.

Moreover, note that the reason the current system was introduced in the
first place was to avoid the quadratic builds. I suppose this is less of
an issue in go-build-system due to the order-of-magnitude difference in
compiler speed on typical source code.

As for re-using build artifacts, once we figure out how to do it, we can
always revert this patch, together with the one that originally added
cargo-inputs. I don't think it's going to be any time soon, though, as
upstream doesn't support this style of building.

Regards,
Jakub Kądziołka

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2020-08-13 16:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-25 21:25 [bug#42049] [PATCH 0/4] build-system/cargo: Propagations across the crate closure Jakub Kądziołka
2020-06-25 21:26 ` [bug#42049] [PATCH 1/4] build-system/cargo: Allow propagating inputs across CARGO-INPUTS edges Jakub Kądziołka
2020-06-25 21:26 ` [bug#42049] [PATCH 2/4] gnu: crates-io: Use propagated-inputs and propagated-native-inputs Jakub Kądziołka
2020-06-25 21:26 ` [bug#42049] [PATCH 3/4] build-system/cargo: Add a propagated-phases argument Jakub Kądziołka
2020-06-25 21:26 ` [bug#42049] [PATCH 4/4] gnu: crates-io: Use propagated-phases Jakub Kądziołka
2020-08-13  9:48 ` [bug#42049] [PATCH 0/4] build-system/cargo: Propagations across the crate closure Efraim Flashner
2020-08-13 16:16   ` Jakub Kądziołka [this message]
2020-08-14 21:26     ` Leo Famulari

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200813161638.ffgfusjplz5zcfgx@gravity \
    --to=kuba@kadziolka.net \
    --cc=42049@debbugs.gnu.org \
    --cc=efraim@flashner.co.il \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).