cargo-build-system should propagate inputs and native-inputs of dependencies

  • Open
  • quality assurance status badge
Details
3 participants
  • Efraim Flashner
  • Jaeme Sifat
  • Mikhail Tsykalov
Owner
unassigned
Submitted by
Mikhail Tsykalov
Severity
normal
M
M
Mikhail Tsykalov wrote on 24 Dec 2023 23:09
(address . bug-guix@gnu.org)
19fc6a13-c5fe-4061-9794-984f07c30fe7@gmail.com
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.
J
J
Jaeme Sifat wrote on 25 Dec 2023 08:45
(address . 68017@debbugs.gnu.org)
208f4c3c-76cf-4106-8c48-cad4261acb86@runbox.com
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
M
M
Mikhail Tsykalov wrote on 25 Dec 2023 09:21
Clarification on why cargo-build-system should propagate inputs and native-inputs.
(address . 68017@debbugs.gnu.org)
43cc2ae9-6026-46a5-acd1-fe813b758ccb@gmail.com
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.
Attachment: av1an.scm
J
J
Jaeme Sifat wrote on 25 Dec 2023 21:02
(address . 68017@debbugs.gnu.org)
6c571648-f982-4b1c-bca3-22cd030b4940@runbox.com
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.

Toggle snippet (12 lines)
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


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
E
E
Efraim Flashner wrote on 27 Dec 2023 11:43
(name . Jaeme Sifat)(address . jaeme@runbox.com)
ZYv_3VWjH6igpjuI@3900XT
On Mon, Dec 25, 2023 at 03:02:22PM -0500, Jaeme Sifat wrote:
Toggle quote (29 lines)
> 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@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
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmWL/9oACgkQQarn3Mo9
g1Gn8g//Tzl9jhIVF9FrE3r9Qmgu71cGamlxbVOtbdilbxDygRgWO8yWbOewIt9B
cXZmvhuYfhZ/8z0bBZoyrjUvnG8dJFrH36BtkP7Y/bLp4Krk4Jq86zYpnCxSXQnp
o7aGmKnUsU8LnzNpCQ460HuSu8Xo3klT92fqRQh83wsT61bR/JYiWSfgKz+EFhjE
4D4JjU7/ZMZM5605uD1pSHJWtJU/ZPdYt54HvMp8WdoMPMBej5UOpfV1i++nnQbT
buExDpFNScxu5bTPjAMsGnIF+CbFx2+luhNGoUmKvJK727izN2/gJaGn7zrtPmAU
n1Khwsa4ZDHUvJ3ufRLapIQtBeqG+GJhd+BbY+R7PScEGc39lVYvF8rAzInKqB3x
6jSFN1bZBvwpVlyxFZ/eb/YHWuleyCREVmoJvwHFQkdckEqgHcziRd8lASAIUPv4
2nGYUFhPnsqt6/0pfHZsBGg/lt4SLmDiwgGlmAjJUPf00TKs1g9tIWvXL98pyum+
FRmoN4c2ZmruY1oTOaHQB0i94YVqnV2GvL46ZwagYqArSEzRm8EYMVAUaCxDpKn3
78iE+FiypSLbvY3N9drx/PsGMls8Jt56FNu3uuYqY1QlP+yaTQtJjWuigmWjrs6m
HrXxxe/JoulXgvuA8ejdvcqppi3olLsIDioXHHttXX03oFyxnFU=
=yHRp
-----END PGP SIGNATURE-----


?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 68017@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 68017
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch