Trivial build system

Trivial build system

[Andreas Enge]

Hello,

in my work on texlive, I am trying to build a package by simply applying
the 'unpack and 'patch-source-shebangs phases of gnu-build-system. A working
approach is to delete all other phases from gnu-build-system, but that would
break the package whenever gnu-build-system is augmented. So I tried to
start from trivial-build-system. But the following code fails:

   (arguments
    `(#:modules ((guix build gnu-build-system)
                 (guix build utils))
      #:builder (begin
                  (use-modules (guix build utils)
                               (guix build gnu-build-system))
                  (let ((out %output)
                        (source (assoc-ref %build-inputs "source"))
                        (unpack (assoc-ref %standard-phases 'unpack)))
                    (format #t "XXX ~a XXX\n" source)
                    (apply unpack (list #:source source))
                    (mkdir-p out)
                    (zero? (system* "mv" "tlpkg" out))
                    ))))

The error message is
In execvp of tar: No such file or directory
In execvp of mv: No such file or directory
XXX /gnu/store/xrm2iibfw8x38b9jjkwbidgw96b6aa6i-texlive-20140525-extra.tar.xz XXX
builder for `/gnu/store/q5w5qp1nh6i1275xkggidpy65fsyifvi-texlive-texmf-2014.drv' failed with exit code 1

I printed the value of SOURCE which contains indeed the source to unpack.
What is my mistake here?

Andreas

Re: Trivial build system

[Andreas Enge]

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.

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.

Andreas

Re: Trivial build system

[David Thompson]

Andreas Enge <andreas@enge.fr> writes:

> in my work on texlive, I am trying to build a package by simply applying
> the 'unpack and 'patch-source-shebangs phases of gnu-build-system. A working
> approach is to delete all other phases from gnu-build-system, but that would
> break the package whenever gnu-build-system is augmented.

Rather than deleting the other known phases, how about just selecting
the 2 phases you are interested in?

  (map (cut assq <> %standard-phases)
       '(unpack patch-source-shebangs))

It's not obvious to me what the problem is with the build system you
have now, sorry.

-- 
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate

Re: Trivial build system

[Andreas Enge]

On Sun, Jan 11, 2015 at 04:12:47PM +0100, Andreas Enge wrote:
> In execvp of tar: No such file or directory

Hm, it looks to me as if "tar" is the file not found and not its argument,
and that I am missing the 'set-paths phase. But this has tons of arguments,
which I do not know how to set in my builder.

I could call "tar" myself, but then I would also need to copy
first-subdirectory from gnu-build-system. So having a trivial-build-system
consisting of the phases 'set-paths and 'unpack from gnu-build-system
would be very useful, and also make packages that currently use the trivial
system more easy to write. (I am taking font-dejavu as a model; we would
not need to set PATH to include bzip2, call tar explicitly and chdir into
the created directory).

Andreas

Re: Trivial build system

[Andreas Enge]

On Sun, Jan 11, 2015 at 10:33:04AM -0500, David Thompson wrote:
> Rather than deleting the other known phases, how about just selecting
> the 2 phases you are interested in?
>   (map (cut assq <> %standard-phases)
>        '(unpack patch-source-shebangs))

Thanks a lot, that did the trick (together with adding the 'set-paths phase),
and I learnt a bit of scheme at the same time! For the record, the final code
snippet looks like this:
   (arguments
    `(#:modules ((guix build gnu-build-system)
                 (guix build utils)
                 (srfi srfi-26))
      #:imported-modules ((guix build gnu-build-system)
                          (guix build utils))
      #:phases
        (alist-cons-after
         'patch-source-shebangs 'install
         (lambda* (#:key outputs #:allow-other-keys)
           (let ((out (assoc-ref outputs "out")))
             (mkdir-p out)
             (zero? (system* "mv" "tlpkg" out))))
         (map (cut assq <> %standard-phases)
              '(set-paths unpack patch-source-shebangs)))))

Andreas

Re: Trivial build system

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> I could call "tar" myself, but then I would also need to copy
> first-subdirectory from gnu-build-system. So having a trivial-build-system
> consisting of the phases 'set-paths and 'unpack from gnu-build-system
> would be very useful, and also make packages that currently use the trivial
> system more easy to write. (I am taking font-dejavu as a model; we would
> not need to set PATH to include bzip2, call tar explicitly and chdir into
> the created directory).

Yeah, perhaps we need some sort of an intermediate between
trivial-build-system and gnu-build-system.

The idea is that trivial-build-system really does nothing (and it does
it well!).  And then, (guix build gnu-build-system) exports its phases,
so it’s always possible to reuse them, as David noted.

Ludo’.

Build system phases

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