GNU bug report logs - #69637
[PATCH mesa-updates 0/6] gnu: mesa: Update to 24.0.2.

Previous Next

Full log

View this message in rfc822 format

From: aurtzy <aurtzy <at> gmail.com>
To: Efraim Flashner <efraim <at> flashner.co.il>
Cc: john.kehayias <at> protonmail.com, 69637 <at> debbugs.gnu.org
Subject: [bug#69637] [PATCH mesa-updates 0/6] gnu: mesa: Update to 24.0.2.
Date: Wed, 20 Mar 2024 21:52:36 -0400

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

On 3/12/24 04:11, Efraim Flashner wrote:
> Are there other architectures which have rust based drivers? x86_64
> isn't the only architecture which has rust building on it.
There doesn't appear to be any official documentation stating 
architecture requirements for Mesa with NVK/Rust, however I have added 
few new inputs other than rust to get NVK working. I've only done 
extensive testing with x86_64 so I was unsure of potential issues with 
including this on other architectures (other than i686 not building rust).
> The crates are also available in
> %output/share/cargo/registry/name-version.crate, although I can't think
> of a good way to address them by name without using find-files.
>
> I would personally replace the versions requested by mesa with whatever
> version we happen to have in guix so that we don't have to add special
> versions just for mesa.

I have/had tried a few approaches to use the crates already available in 
Guix with no success so far. I've outlined the approaches below; still 
looking into solutions, but perhaps there's something I'm missing or 
haven't tried yet?

- Simply including crates as (native-)inputs does not make them 
discoverable by meson.

- Mesa uses these *.wrap files which specify the rust dependency 
versions, source URLs, and tar hashes. I currently get the build working 
by relying on meson to fall back to "downloading" from a patched source 
URL (pointing to store), although it still has to match the hash.

- I recently discovered a way to disable the hash requirement so I could 
use a different input version (i.e. one from Guix), but doing it causes 
"File src/lib.rs does not exist" errors. I'm still looking into this 
right now, as it seems promising.

- Old IRC logs point to projects like newsboat and librsvg which also 
mix cargo with with another build system, but these start with 
cargo-build-system with phases added/replaced from the second build 
system. Cargo.toml doesn't exist in Mesa either (which 
cargo-build-system seems to depend on), so experimenting with using 
cargo-build-system didn't yield much.

I wanted to look more into the third bullet before responding, but I 
felt it would be unfortunate to have this information rot while trying 
to make time for hacking - hopefully it's still useful.

Cheers,

aurtzy

[Message part 2 (text/html, inline)]

Previous Next

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