Hi Daniel :) I remember writing a very simple build system a long time ago and being as flabbergasted as you are now. Almost all the code was all boilerplate
https://gitlab.com/edouardklein/guix/-/blob/e154d745d6bcc92fc183b66f243eeb31959e95cd/guix/build-system/gerbil.scm Then the payload was: https://gitlab.com/edouardklein/guix/-/blob/e154d745d6bcc92fc183b66f243eeb31959e95cd/guix/build/gerbil-build-system.scm I can't write a more detailed answer right now but I believe you will find the comments of that latter file helpful. Also, the short story is the "magic" happens in the _phases_, so you "just" need to redefine, reorder, replace, etc. the phases to invoke the commands you need. For gerbil is was simply a matter of calling ./build.ss: https://gitlab.com/edouardklein/guix/-/blob/e154d745d6bcc92fc183b66f243eeb31959e95cd/guix/build/gerbil-build-system.scm#L63 Sorry for the lack of time to write a more complete answer, but I hope you'll find those pointers helpful. Cheers, Edouard. Daniel Littlewood <[email protected]> writes: > Hi help-guix, > > I am trying to write a package for a recent version of docker. Docker packages > itself via a Dockerfile, so I figured the build process would be > idiosyncratic & > probably would not work with the packaged go-build-system. For this reason > (and > also purely for education) I am trying to write a build-system. I am having a > lot of trouble with that! > > There are some things I understand clearly. First that since builds happen in > the "build environment" that there are differences between "normal code" and > "build code", and that you have to wrap "build code" up in a g-expression. > This > explains some things that are not intuitive to me at first glance, like having > to re-import modules. And also that since all build dependencies have to be > stated explicitly, that you cannot just assume that any standard utilities are > available, you have to make sure you state them explicitly. > > I can also see in the manual that build-systems are high level objects, which > are compiled to low-level "bags" and then to even lower-level derivations, > which > the build daemon can, well, build. However I cannot see anywhere a mental > picture for how to think of "what is a bag" or even "what is a build system". > I > get the very most basic thing, that a build system is a bit like a procedure > for > turning package metadata into a store item, but I cannot see anywhere that > logic > actually exists. When I go to look inside the actual build system source code > (like for copy-build-system or ruby-build-system, which seem relatively > simple) > I can't find any line of code that says "copy this file from the source to the > output" or "run this script" or "ensure these env vars are set" or "ensure > these > directories exist". > > Weirdly I can see the sort of thing I'm imagining in the "Dissecting guix: > g-expressions" blog post, but I can't match up the examples there with any of > the actually implemented build systems. > > For example in copy-build-system, I see the function "lower". It looks roughly > like this: > > (define* (lower ...) > (bag ... > (build copy-build))) > > where the abbreviated parts seem to only be boilerplate. So I go to look at > copy-build, which looks to me roughly like this: > > (define* (copy-build ...) > (define builder > #~(copy-build ...) > (mlet %store-monad ((guile ...)) > (gexp->derivation name builder ...)) > > so I can see where we go from a package to a bag to a derivation. But where > does > "stuff happen"? Where does the copy-build-system copy things? > > I feel like it's bad manners to ask for help without posting code, so I did > try > writing a docker build system, and it is broken in a way I don't understand. > I've written a package and a build system, which I'm running with > > guix build -L. -f docker.scm > > I've attached docker.scm, docker-build-system.scm and the error trace which > abbreviates to: > > no code for module (guix build-system) > > This is very confusing to me, because the build systems I am cargo-culting > from > do not seem to declare this module anywhere, apart from declaring that they do > use it. It looks to me like the build process is expecting this module, so it > should be in with-imported-modules, but I don't know why the build process > expects it, since I don't think I use it in the build code. > > Anyway, thank you for reading, hopefully someone can point me in the right > direction. > > Dan Littlewood
