Re: Current state of cargo-build-system

[Ivan Petkov <ivanppetkov@gmail.com>]

Answering my own question after digging through the guix source, maybe someone
can correct me if I’ve gotten things wrong!

> On Jan 25, 2019, at 3:57 PM, Ivan Petkov <ivanppetkov@gmail.com> wrote:
> 
> However, it appears that guix still insists on building the entire package even
> if we only depend on the "src" output. Is it possible to lazily build packages
> based on the type of dependency? Is this something the build system can finagle,
> or is this an inherent limitation to guix?

So it appears that guix takes package definitions and feeds them to their
respective build system, which then get lowered to a bag (a more low-level
representation of a package). The bag is then built as the actual derivation.

Thus it is possible for the build system to do any kind of preprocessing of the
dependency closure or even produce dynamic/hidden packages if neccessary (but is
this discouraged?).

It also appears that guix expects to build the package entirely and it allows
the build system to split up the result into various outputs, but there isn't a
notion of lazily building out only the required outputs (I suppose the real
solution to this would be to break up the package definition in the appropriate
way to support this).

I have some ideas on how to resolve our cargo woes, namely by introducing
crate-source-only packages that don't actually get built and substitute those
for any potential cycles. I'd like to make imports and maintenance of package
definitions as simple as possible, so I'd like to explore making the build
system a bit more clever in handling this.

Will do some more prototyping on my own and report back!

--Ivan