GNU bug report logs - #35318
[PATCH] Update cargo-build-system to expand package inputs

Previous Next

Full log

Message #32 received at 35318 <at> debbugs.gnu.org (full text, mbox):

From: Ivan Petkov <ivanppetkov <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Danny Milosavljevic <dannym <at> scratchpost.org>, 35318 <at> debbugs.gnu.org,
 Chris Marusich <cmmarusich <at> gmail.com>
Subject: Re: [bug#35318] [PATCH] Update cargo-build-system to expand package
 inputs
Date: Sun, 19 May 2019 18:00:01 -0700

[Message part 1 (text/plain, inline)]

Hi everyone!

I’ve updated this patch series. The cargo-build-system will now expect any
crate dependencies to be listed as arguments. Specifically, regular cargo
dependencies should be specified via the #:cargo-deps parameter, and any cargo
dev-dependnecies should be specified via the #:cargo-dev-deps parameter.

The cargo-build-system will traverse any inputs specified in those parameters,
and any inputs they may have in their #:cargo-deps parameter as well,
extracting their package sources and adding them as native-inputs to the
current bag being built. This avoids having to define new semantics for package
inputs/native-inputs for expanding all transitive sources.

There are several implications of this decision:
* Building a package definition does not require actually building/checking
any dependent crates. This can be a benefits:
 - For example, sometimes a crate may have an optional dependency on some OS
 specific package which cannot be built or run on the current system. This
 approach means that the build will not fail if cargo ends up internally ignoring
 the dependency.
 - It avoids waiting for quadratic builds from source: cargo always builds
 dependencies within the current workspace. This is largely due to Rust not
 having a stable ABI and other resolutions that cargo applies. This means that
 if we have a depencency chain of X -> Y -> Z and we build each definition
 independently the following will happen:
  * Cargo will build and test crate Z
  * Cargo will build crate Z in Y's workspace, then build and test Y
  * Cargo will build crates Y and Z in X's workspace, then build and test X
* But there are also some downsides with this approach:
  - If a dependent crate is subtly broken on the system (i.e. it builds but its
  tests fail) the consuming crates may build and test successfully but
  actually fail during normal usage (however, the CI will still build all
  packages which will give visibility in case packages suddenly break).
  - Because crates aren't declared as regular inputs, other Guix facilities
  such as tracking package graphs may not work by default (however, this is
  something that can always be extended or reworked in the future).

Please let me know if anything is unclear, I’m happy to elaborate if needed!

Thanks,
—Ivan

[0001-build-system-cargo-expand-transitive-crate-sources.patch (application/octet-stream, attachment)]

[0002-build-system-cargo-use-sources-from-package-sources.patch (application/octet-stream, attachment)]

[0003-build-system-cargo-don-t-copy-source-as-an-output.patch (application/octet-stream, attachment)]

[0004-doc-Update-cargo-build-system-parameter-docs.patch (application/octet-stream, attachment)]

[0005-import-crate-import-sources-with-.crate-extension.patch (application/octet-stream, attachment)]

[0006-import-crate-define-dependencies-as-arguments.patch (application/octet-stream, attachment)]

[0007-gnu-crate-add-unicode-xid.patch (application/octet-stream, attachment)]

[0008-gnu-crate-Add-proc-macro2-and-quote.patch (application/octet-stream, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.