Re: Use and abuse of ‘computed-origin-method’: the ‘rust-ring’ case

["Ludovic Courtès" <ludo@gnu.org>]

Hi!

Efraim Flashner <efraim@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’.