Build system phases

[ludo@gnu.org (Ludovic Courtès)]

Andreas Enge <andreas@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’.