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