* Trivial build system
@ 2015-01-11 15:12 Andreas Enge
2015-01-11 15:25 ` Andreas Enge
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Andreas Enge @ 2015-01-11 15:12 UTC (permalink / raw
To: guix-devel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Trivial build system
2015-01-11 15:12 Trivial build system Andreas Enge
@ 2015-01-11 15:25 ` Andreas Enge
2015-01-12 9:31 ` Build system phases Ludovic Courtès
2015-01-11 15:33 ` Trivial build system David Thompson
2015-01-11 15:38 ` Andreas Enge
2 siblings, 1 reply; 7+ messages in thread
From: Andreas Enge @ 2015-01-11 15:25 UTC (permalink / raw
To: guix-devel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Trivial build system
2015-01-11 15:12 Trivial build system Andreas Enge
2015-01-11 15:25 ` Andreas Enge
@ 2015-01-11 15:33 ` David Thompson
2015-01-11 16:44 ` Andreas Enge
2015-01-11 15:38 ` Andreas Enge
2 siblings, 1 reply; 7+ messages in thread
From: David Thompson @ 2015-01-11 15:33 UTC (permalink / raw
To: Andreas Enge, guix-devel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Trivial build system
2015-01-11 15:12 Trivial build system Andreas Enge
2015-01-11 15:25 ` Andreas Enge
2015-01-11 15:33 ` Trivial build system David Thompson
@ 2015-01-11 15:38 ` Andreas Enge
2015-01-12 9:25 ` Ludovic Courtès
2 siblings, 1 reply; 7+ messages in thread
From: Andreas Enge @ 2015-01-11 15:38 UTC (permalink / raw
To: guix-devel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Trivial build system
2015-01-11 15:33 ` Trivial build system David Thompson
@ 2015-01-11 16:44 ` Andreas Enge
0 siblings, 0 replies; 7+ messages in thread
From: Andreas Enge @ 2015-01-11 16:44 UTC (permalink / raw
To: David Thompson; +Cc: guix-devel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Trivial build system
2015-01-11 15:38 ` Andreas Enge
@ 2015-01-12 9:25 ` Ludovic Courtès
0 siblings, 0 replies; 7+ messages in thread
From: Ludovic Courtès @ 2015-01-12 9:25 UTC (permalink / raw
To: Andreas Enge; +Cc: guix-devel
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’.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Build system phases
2015-01-11 15:25 ` Andreas Enge
@ 2015-01-12 9:31 ` Ludovic Courtès
0 siblings, 0 replies; 7+ messages in thread
From: Ludovic Courtès @ 2015-01-12 9:31 UTC (permalink / raw
To: Andreas Enge; +Cc: guix-devel
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’.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-01-12 9:31 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-01-11 15:12 Trivial build system Andreas Enge
2015-01-11 15:25 ` Andreas Enge
2015-01-12 9:31 ` Build system phases Ludovic Courtès
2015-01-11 15:33 ` Trivial build system David Thompson
2015-01-11 16:44 ` Andreas Enge
2015-01-11 15:38 ` Andreas Enge
2015-01-12 9:25 ` Ludovic Courtès
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.