Andreas Enge <andr...@enge.fr> skribis:
> I also wonder if we should not modify the structure of our build system code.
> Our different build systems end up calling gnu:gnu-build with a list of
> phases.
That’s intended. “Phases” are a build-side entity, and so they get
composed on the build side, for instance by reusing ‘gnu-build’ or
‘%standard-phases’.
> Could this not be done all the time? And then a build system be defined as
> a list of phases? For instance, trivial-build-system could be the empty
> list, or better yet, the list containing 'unpack.
>
> Then we could always take the #:phases argument of a package and modify it
> by adding a phase, for instance; this would be easier than taking a #:build
> argument and modify it, I think.
Initially the idea was to leave phases as an “implementation detail” of
the build system, something that happens on the build side.
There are two questions, I think:
1. Could we move phases to the host side–i.e., somehow make them
first-class objects that could be more easily manipulated?
2. Should phases be an integral part of all build systems?
There may be something to do with #1. It’s tricky because it has to be
done in a way that does not increase the amount of computation done when
loading package modules, and that does not significantly increase memory
requirements either.
I’m not sure about #2.
Thoughts?
Ludo’.
