[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 'guix environment' as a build tool.
From: |
Ludovic Courtès |
Subject: |
Re: 'guix environment' as a build tool. |
Date: |
Sun, 31 Jul 2016 13:13:53 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Hello,
Mathieu Lirzin <address@hidden> skribis:
> address@hidden (Ludovic Courtès) writes:
>
>> Mathieu Lirzin <address@hidden> skribis:
>>
>>> I have tested successfully with the following command on a foreign
>>> system:
>>>
>>> guix environment --ad-hoc automake pkg-config guile guix libgcrypt sqlite
>>> guile-sqlite3
>>>
>>> Tell me if it works for you.
>>>
>>>> How about including a guix package definition then we can easily build
>>>> it assuming "we" know how to do out-of-guix-tree package building :)
>>>
>>> It would indeed be nice to provide an easy way for Guix users to install
>>> Cuirass. IMHO package definitions meant as a development build tool is
>>> confusing and should be avoided. Nonetheless, I think it is useful to
>>> document the previous 'guix environment ...' command in the README.
>>
>> What about providing a ‘guix.scm’ file that people could pass to ‘guix
>> environment -l’ (instead of typing the long command above), and to ‘guix
>> package -f’ (info "(guix) Invoking guix package")?
>
> 'guix environment -l' uses a package definition. To me this abstraction
> doesn't fit well in a development context:
>
> - the origin hash doesn't make sense.
Not a problem with ‘local-file’, as David wrote.
> - packages already included in Guix have redundant description and synopsis.
Yeah, though for such packages, a guix.scm is typically less useful
since most of the time ‘guix environment PACKAGE’ is enough.
> - package definitions rely on Guix internals.
I sympathize both with this and with what David wrote here.
I can sympathize with the idea that conceptually a package definition is
not quite the same thing as a development environment definition, in
practice ‘guix environment -l’ remains much better than the long command
line above. :-)
> An idea that I like better and is less invasive, would be to complement
> bootstrap scripts with:
>
> ./bootstrap --with-guix
>
> This command would:
>
> - generate a guix-env script that wraps 'guix environment ...' if it
> doesn't exist.
> - Invoke ./guix-env
> - Invoke autoreconf -vfi
>
> if the user wants to enter this environment Later it will have to invoke
> './guix-env'.
I’m not convinced by generated scripts.
Now, we’re at a stage where everyone is welcome to explore their own
way. Some may prefer a ‘guix.scm’ file, while others would prefer a
script that runs ‘guix environment --ad-hoc’. With more experience,
maybe we can come up with a solution that better caters to everyone’s
needs.
Thanks,
Ludo’.
- Re: [GSoC] Continuous integration tool à la Hydra., (continued)
- Re: [GSoC] Continuous integration tool à la Hydra., Florian Paul Schmidt, 2016/07/29
- Re: [GSoC] Continuous integration tool à la Hydra., Mathieu Lirzin, 2016/07/29
- Re: [GSoC] Continuous integration tool à la Hydra., Ludovic Courtès, 2016/07/30
- 'guix environment' as a build tool. (was: [GSoC] Continuous integration tool à la Hydra.), Mathieu Lirzin, 2016/07/30
- Re: 'guix environment' as a build tool. (was: [GSoC] Continuous integration tool à la Hydra.), Thompson, David, 2016/07/30
- Re: 'guix environment' as a build tool., Mathieu Lirzin, 2016/07/31
- Re: 'guix environment' as a build tool., Ludovic Courtès, 2016/07/31
- Re: 'guix environment' as a build tool., Thompson, David, 2016/07/31
- Re: 'guix environment' as a build tool., Ludovic Courtès, 2016/07/31
- Re: 'guix environment' as a build tool.,
Ludovic Courtès <=
- Re: [GSoC] Continuous integration tool à la Hydra., Florian Paul Schmidt, 2016/07/31
- Re: [GSoC] Continuous integration tool à la Hydra., Mathieu Lirzin, 2016/07/31