Hi! Efraim Flashner <efr...@flashner.co.il> skribis:
>> Anyway, the ‘computed-origin-method’ hack prevents input rewriting from >> working as expected because the inputs of that big gexp aren’t visible >> by just traversing the package graph. That’s a problem. > > Are we talking about the inputs used for the computed-origin? (perl, > nasm, go, etc?) Yes. > I'm pretty sure there are 3 options here: > 1. Stop rebuilding the generated files. This is what we did in the past, > and it allows rust-ring-0.14 to be used on riscv64-linux. I haven't > talked with the Debian folks about it but I'm pretty sure this is what > they currently do. I don't like it because we have instructions on how > to do the rebuild and it's already implemented. I also really like that > everything can be regenerated from (nearly) any architecture, which > makes it a much nicer build than qemu, which needs many cross compilers. Yeah, we’d rather build from source. > 2. Use the trivial-build-system instead of a computed-origin-method. > I'm pretty sure we can use the output of the trivial-build-system (or > any other package build) as the source for another package. I > currently think this is the best option. Yes, that should work. > 3. Adjust the build.rs file in rust-ring to call a custom shell script > which will build all the missing files that we would remove in a > snippet. This is probably best from a "the source is ready to hack on" > perspective, but it means we're carrying around a custom build script > with no chance of being upstreamed. It also means that each package > which uses rust-ring will need to have all the rust-ring build > dependencies added and it will need to be built each time. > > I've attached a patch that I tested locally to build the sources in an > actual package, and then use that to build rust-ring. I tested it by > building librsvg. Currently it still requires go itself as using gccgo > needs gccgo-toolchain. Nice! > + (package > + (name "rust-ring") > + (version "0.17.8.tar.gz") ; Hack to adjust the output name. > + (source (origin > (method git-fetch) > (uri (git-reference > (url "https://github.com/briansmith/ring";) > @@ -4147,182 +4148,185 @@ (define rust-ring-0.17-sources > (file-name (git-file-name "rust-ring" version)) > (sha256 > (base32 > "0rqfal81bf4l3dja98cajfjq2jbz1rcx7xdp2r33cxrm5y5psr28")) [...] > + (build-system trivial-build-system) > + (arguments > + (list > + #:modules '((guix build utils)) > + #:builder > + #~(begin > + (use-modules (guix build utils)) > + (setenv "PATH" > + (string-join > + (list (assoc-ref %build-inputs "clang") ; for > clang-format > + (assoc-ref %build-inputs "go") > + (assoc-ref %build-inputs "gzip") > + (assoc-ref %build-inputs "nasm") > + (assoc-ref %build-inputs "perl") > + (assoc-ref %build-inputs "python-minimal") > + (assoc-ref %build-inputs "tar")) You could use #+(this-package-native-input "clang"), etc. If it works, I’m all for it! I wonder if another option would be to make a proper package, which would install the generated headers to $output/include and the generated .o files to #$output/lib. That package could be among the ‘propagated-inputs’ of ‘rust-ring’. Dunno if that would work though. Thanks for the quick reply & fix! Ludo’.
