GNU bug report logs - #68017
cargo-build-system should propagate inputs and native-inputs of dependencies

Previous Next

To reply to this bug, email your comments to 68017 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Mikhail Tsykalov <tsymsh <at> gmail.com>
To: bug-guix <at> gnu.org
Subject: cargo-build-system should propagate inputs and native-inputs of
 dependencies
Date: Mon, 25 Dec 2023 01:09:13 +0300

Considering cargo-inputs are built when top package is built it makes 
sense to propagate their inputs and native-inputs to top package. 
Currently you have to either track them manually or figure them out from 
build errors.

NB: This is my first time packaging rust, so I may be wrong about stuff.

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

From: Jaeme Sifat <jaeme <at> runbox.com>
To: 68017 <at> debbugs.gnu.org
Subject: Re: cargo-build-system should propagate inputs and native-inputs of
 dependencies
Date: Mon, 25 Dec 2023 02:45:56 -0500

I'm a bit confused about what you exactly mean. Can you provide an 
example? Programmatically, the build-system isn't supposed to be 
reflected (package components of the build-system) in the inputs fields 
of packages, Rust is no different.

> NB: This is my first time packaging rust, so I may be wrong about stuff.

The typical way of creating Rust crate definitions is to use `guix 
import crate <package-name-on-crates.io>' to obtain a template 
definition that you'd refine after building and testing the package. If 
the crate is not hosted on crates.io, then you would have to read the 
`Cargo.toml' file for build instructions. The guix import command also 
has a '--recursive' option to automate that process for all the 
dependencies of a crate as well. It's a repetitive process for sure, but 
you don't have to find out dependencies by build errors.

--

Jaeme

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

From: Mikhail Tsykalov <tsymsh <at> gmail.com>
To: 68017 <at> debbugs.gnu.org
Subject: Clarification on why cargo-build-system should propagate inputs and
 native-inputs.
Date: Mon, 25 Dec 2023 11:21:31 +0300

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

I didn't get CC'd for some reason.

Okay, I have an example package (attached). Hardly a good reproducer, 
but that's what I have. Mostly created by using 'guix import' and 
editing things. You can build it using 'guix build -L. av1an' in the 
directory with the file. If you want it to not segfault, you'll have to 
install python in profile (that's probably a bug in vapoursynth package).

What I want you to do is to remove clang and nasm from input field of 
av1an package and try to build it. It will crash while building 
rust-bindgen. Neither clang nor nasm are things that av1an depends on, 
they are dependencies of a dependency of a dependency, yet for some 
reason omitting them from inputs field will make a package fail to 
build. pkg-config is in similar situation.

So, my suggestion is to make cargo-build-system propagate inputs and 
native-inputs fields of packages dependent by cargo-inputs to top level 
package.

[av1an.scm (text/x-scheme, attachment)]

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

From: Jaeme Sifat <jaeme <at> runbox.com>
To: 68017 <at> debbugs.gnu.org
Cc: efraim <at> flashner.co.il, tsymsh <at> gmail.com
Subject: Re: Clarification on why cargo-build-system should propagate inputs
 and native-inputs.
Date: Mon, 25 Dec 2023 15:02:22 -0500

The culprit to your problem is `rust-ffmpeg-sys-the-third-1', which 
requires all the packages you just mentioned for building. 
`rust-av1an-core` requires `rust-ffmpeg-the-third-1' which in turn 
requires the sys libraries as well.

--8<---------------cut here---------------start------------->8---

rust-ffmpeg-sys-the-third-1 -> Requires vapoursynth ffmpeg clang nasm 
pkg-config

rust-ffmpeg-the-third-1 -> Requires rust-ffmpeg-sys-the-third-1

rust-av1an-core -> Requires rust-ffmpeg-the-third-1

rust-av1an -> Requires rust-av1an-core

--8<---------------cut here---------------end--------------->8---

Thus, the native-inputs and inputs of rust-ffmpeg-sys-the-third are 
required for any packages that depend on it in #:cargo-inputs.

I see your point now, it would be very helpful if cargo-build-system 
could grab the inputs and native-inputs of dependent packages in the 
case of crates like `rust-ffmpeg-sys-the-third-1.' That way the 
dependencies wouldn't have to be duplicated across packages.

This sounds like a good suggestion, I can bring this up to Efraim, who 
is on the Rust team, about this who is much more knowledgeable about the 
implementation of the cargo-build-system than me.

--

Jaeme

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

From: Efraim Flashner <efraim <at> flashner.co.il>
To: Jaeme Sifat <jaeme <at> runbox.com>
Cc: 68017 <at> debbugs.gnu.org, tsymsh <at> gmail.com
Subject: Re: Clarification on why cargo-build-system should propagate inputs
 and native-inputs.
Date: Wed, 27 Dec 2023 12:43:41 +0200

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

On Mon, Dec 25, 2023 at 03:02:22PM -0500, Jaeme Sifat wrote:
> The culprit to your problem is `rust-ffmpeg-sys-the-third-1', which requires
> all the packages you just mentioned for building. `rust-av1an-core` requires
> `rust-ffmpeg-the-third-1' which in turn requires the sys libraries as well.
> 
> --8<---------------cut here---------------start------------->8---
> 
> rust-ffmpeg-sys-the-third-1 -> Requires vapoursynth ffmpeg clang nasm
> pkg-config
> 
> rust-ffmpeg-the-third-1 -> Requires rust-ffmpeg-sys-the-third-1
> 
> rust-av1an-core -> Requires rust-ffmpeg-the-third-1
> 
> rust-av1an -> Requires rust-av1an-core
> 
> --8<---------------cut here---------------end--------------->8---
> 
> Thus, the native-inputs and inputs of rust-ffmpeg-sys-the-third are required
> for any packages that depend on it in #:cargo-inputs.
> 
> I see your point now, it would be very helpful if cargo-build-system could
> grab the inputs and native-inputs of dependent packages in the case of
> crates like `rust-ffmpeg-sys-the-third-1.' That way the dependencies
> wouldn't have to be duplicated across packages.
> 
> This sounds like a good suggestion, I can bring this up to Efraim, who is on
> the Rust team, about this who is much more knowledgeable about the
> implementation of the cargo-build-system than me.

I haven't looked too closely at that part of the cargo-build-system but
in general my mental model is that it grabs the sources of the named
packages in the cargo{,-development}-inputs. I suppose we could tell the
crates to also grab the {propagated-,native-,}inputs also and carry
those forward to the next crate.  I suppose in theory we might end up
with multiple versions of libgit2 or other packages, and I'm not sure if
that'd point to various packages having the wrong inputs or needing to
adjust it somehow to prefer one version over another.

A similar issue is the perl dependency for rust-ring. I've finally fixed
it on the rust-team branch using a computed-origin but I think both are
the type of thing the antioxidant build system would help solve.

I suppose we could end up with using propagated-inputs for things like
perl or ffmpeg (in your package above) like we do with the python build
systems and adjusting the cargo-build-system to grab those when it
traverses the tree.

-- 
Efraim Flashner   <efraim <at> flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[signature.asc (application/pgp-signature, inline)]

Previous Next

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