Thanks for bringing this up!  rust-ring, while an interesting experiment
in how to package software which doesn't play well with rebuilding
sources, is certainly not something we want to have be the norm.

On Sat, Dec 14, 2024 at 11:37:53PM +0100, Ludovic Courtès wrote:
> Hello Guix,
> 
> ‘rust-ring-0.16-sources’ & co. are origins that use
> ‘computed-origin-method’ (the thing that’s internal and undocumented) to
> generate object files from assembly source, things like that.
> 
> An origin is supposed to represent source code, and clearly, the end
> result here is not source by any stretch.
> 
> I believe it’s done this way simply because ‘cargo-build-system’ then
> embarks that “source” to build leaf package(s) that use ‘rust-ring’,
> directly or indirectly; this is where Rust compilation actually takes
> place and, IIUC, the reason why a build phase in ‘rust-ring’ would be of
> no use.

That's correct.  If we went the normal route and removed all the
pre-generated files in a snippet and rebuilt them during the actual
package build that would only work for that package, and we'd have to
duplicate that for each package which uses rust-ring.

> 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?)

> Ideas on how to fix that?
> 
> An idea that comes to mind is to turn ‘rust-ring-0.16-sources’ into a
> package using ‘trivial-build-system’, though I’m not sure it would work
> well with ‘cargo-build-system’.

The main problem we're faced with here is that "the source" (as rustc
defines it) isn't to be touched during the build.  Hence almost
everything that is rebuilt is put into the pregenerated folder in the
sources.  There are a couple of files that are generated outside of the
pregenerated directory, and none that are expected to be generated in
the target directory.

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.

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.

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.


On a side note, I would like to point out that we also use this for
linux-libre and for icecat.


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