all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Efraim Flashner <efraim@flashner.co.il>
To: Jaeme Sifat <jaeme@runbox.com>
Cc: 68017@debbugs.gnu.org, tsymsh@gmail.com
Subject: bug#68017: Clarification on why cargo-build-system should propagate inputs and native-inputs.
Date: Wed, 27 Dec 2023 12:43:41 +0200	[thread overview]
Message-ID: <ZYv_3VWjH6igpjuI@3900XT> (raw)
In-Reply-To: <6c571648-f982-4b1c-bca3-22cd030b4940@runbox.com>

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

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@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

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

      reply	other threads:[~2023-12-27 10:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-24 22:09 bug#68017: cargo-build-system should propagate inputs and native-inputs of dependencies Mikhail Tsykalov
2023-12-25  7:45 ` Jaeme Sifat via Bug reports for GNU Guix
2023-12-25  8:21 ` bug#68017: Clarification on why cargo-build-system should propagate inputs and native-inputs Mikhail Tsykalov
2023-12-25 20:02 ` Jaeme Sifat via Bug reports for GNU Guix
2023-12-27 10:43   ` Efraim Flashner [this message]

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

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

  git send-email \
    --in-reply-to=ZYv_3VWjH6igpjuI@3900XT \
    --to=efraim@flashner.co.il \
    --cc=68017@debbugs.gnu.org \
    --cc=jaeme@runbox.com \
    --cc=tsymsh@gmail.com \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.