guix-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 6/7] guix build: Add 'build-package'.


From: Alex Kost
Subject: Re: [PATCH 6/7] guix build: Add 'build-package'.
Date: Sun, 06 Sep 2015 12:03:38 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Ludovic Courtès (2015-08-28 12:24 +0300) wrote:

> Alex Kost <address@hidden> skribis:
>
>> Ludovic Courtès (2015-08-26 14:12 +0300) wrote:
>>
>>> Alex Kost <address@hidden> skribis:
>>>
>>>> Ludovic Courtès (2015-08-18 17:15 +0300) wrote:
>>>>
>>>>> Alex Kost <address@hidden> skribis:
>>>>>
>>>>>> * guix/scripts/build.scm (build-package): New procedure.
>>>>>
>>>>> [...]
>>>>>
>>>>>> +(define (build-package package . build-options)
>>>>>> +  "Build PACKAGE using BUILD-OPTIONS."
>>>>>> +  (with-store store
>>>>>> +    (let* ((drv (run-with-store store
>>>>>> +                  (package->derivation package)))
>>>>>> +           (drvs (list drv)))
>>>>>> +      (apply set-build-options store build-options)
>>>>>> +      (show-what-to-build store drvs)
>>>>>> +      (build-derivations store drvs)
>>>>>> +      (show-derivation-outputs drv))))
>>>>>
>>>>> I think this doesn’t fit here because it isn’t actually used by ‘guix
>>>>> build’.  Maybe keep it in emacs/ for now?
>>>>
>>>> If you mean "guix-main.scm", I don't think it's the right place either,
>>>> as all this guix-devel stuff does not depend on Guix REPL (or on any
>>>> code from "guix-main.scm" in general).  Besides, "guix-main.scm" doesn't
>>>> provide a module.
>>>>
>>>> What about making some additional module?: (guix devel) or something.
>>>> Other similar code may be put there in future.  For example, you are
>>>> editing a package definition and you may want to download the current
>>>> origin source.  It will probably also require some specific scheme code,
>>>> which may be added to that module.
>>>
>>> Maybe ‘build-package’ could go to (guix packages)?
>>
>> ‘build-package’ uses ‘show-…’ procedures from (guix ui) module.  I
>> thought that adding this module to (guix packages) was not desired, or
>> is it OK?
>
> Right, sorry.  So maybe leave in (guix build scripts) with a comment
> explaining that it doesn’t have a better place and is for use by the
> Emacs UI.  (Make sure to use the monadic style as suggested in a
> previous message.)
>
> Could you send an updated patch?

Yes, sorry for the delay.  At some point I noticed that ‘build-package’
doesn't show any build output, and I had a hard time trying to find out
what's wrong.  Eventually it appeared to be totally unrelated to the
code itself.  I think it's a Geiser bug, but I don't know how to make a
guix independent recipe — I have sent a message describing it in details
to guix-devel — I hope you could help with it :-)

So I am attaching 2 patches here: for adding ‘set-build-options*’ and
for adding ‘build-package’.

Now about the second patch.  At first, I don't agree with it :-).  I
added #:dry-run? to ‘build-package’ procedure as I think it may be
useful, then I found a nice ‘maybe-build’ procedure in (guix scripts
system), and I just moved it to (guix scripts build) which doesn't seem
right.

We have some code in (guix scripts …) that is rather common (I mean not
specific to the current module), but there is no better place for it,
usually because it uses (guix ui).

So what about making (guix scripts) module for such general stuff?
I think we can move there ‘maybe-build’, ‘%standard-build-options’,
‘set-build-options-from-command-line(*)’, ‘show-build-options-help’,
perhaps exported procedures from (guix scripts package).  And
‘build-package’ may also go there, WDYT?

Or maybe just put those things into (guix ui)?

Attachment: 0001-store-Add-set-build-options.patch
Description: Text Data

Attachment: 0002-guix-build-Add-build-package.patch
Description: Text Data


reply via email to

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