[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Build system phases

From: Ludovic Courtès
Subject: Build system phases
Date: Mon, 12 Jan 2015 10:31:22 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

Andreas Enge <address@hidden> 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

> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]