Using Guix as a build system back-end

[Skyler Ferris]

(split from the "On a Guile-based Build-Tool complimenting Guix" thread 
because, as noted in the quote, using Guix as a backend is tangential to using 
Guile as a frontend)

Hello,

> This is somewhat tangential to creating a Guile-base build tool, but I
> think it's something we should address once the build daemon provides
> enough flexibility. I'm hopping that the rewrite of the build daemon
> will solve my concerns.

Could you expand on the limitations of the build daemon? From my understanding 
(which is purely theoretical, I have not used the low-level daemon API myself) 
it provides the tools that we need to do this. It's just a matter of 
decomposing the build into separate derivations. For example, let's say we have 
a Makefile like this:

```
executable: support.o main.o
  gcc support.o main.o -o executable

main.o: main.c
  gcc main.c -c -o main.o

support.o: support.c
  gcc support.c -c -o support.o
```

If Make was using Guix as a backend it would create 3 separate derivations, one 
for each target. The derivation for support.o would reference support.c (which 
would be added to the store with something like "add-text-to-store") and it 
would automatically construct a builder that runs the gcc invocation in a 
shell. This should be sufficient for incremental builds (if main.c changes the 
new build can re-use the store's copy of main.o) and transparent artifact 
sharing (if there is another location in the filesystem that uses the same gcc 
invocation and the same text in support.o, it will come out to be the same 
derivation and so the store's copy of main.o can again be used).

Regards,
Skyler (they/them)