Re: 'guix build [P]' followed by 'guix install /gnu/store/[...]' vs. 'guix install [P]'

[Ludovic Courtès]

Hello!

Thomas Schwinge <tschwinge@baylibre.com> skribis:

>> The reason is that when you run:
>>
>>   guix install gcc-toolchain
>>
>> ‘gcc-toolchain’ is a live package with metadata that Guix uses when it
>> builds the profile, in particular data about search paths.
>>
>> However, when you run:
>>
>>   guix package -i /gnu/store/…
>>
>> then all Guix sees is an inert store item with no associated metadata.
>> This is why it ends up creating a profile without search path info.
>
> Hmm, I see.  That also matches what Rutherther had written on IRC.
> However, conceptually, I don't understand the rationale for doing it this
> way.  Isn't this Guix use of 'C_INCLUDE_PATH' etc. intimately specific to
> the way how GCC has to be built/used in the Guix context?  Therefore, I'd
> expect such setup code to be an artifact (meta data) of 'guix build',
> that is, written into '/gnu/store/[...]-gcc-toolchain-4.8.5/etc/profile'
> at 'guix build' time, instead of into the '[Guix profile]/etc/profile'
> created by 'guix install', and 'guix install' would then just use that
> file (like, add to the '[Guix profile]/etc/profile' a shell
> 'source /gnu/store/[...]-gcc-toolchain-4.8.5/etc/profile').

Yeah, I understand this can be confusing; it has to do with metadata
only existing in package definitions and not in the build output in
/gnu/store.

>> This is one of the reasons why I would recommend against that second
>> method.  It might be useful as a last resort but should be avoided as
>> much as possible.
>
> Hmm.  But is it really a good idea then at all, to offer this way of
> 'guix install'ing packages, if it can't be expected to work reliably?

It can be helpful in “rescue mode” so to speak, but honestly, I haven’t
used it in years and I thought nobody knew about it.  :-)

Maybe we should document it less prominently and/or add warnings against
it, at least.

> What is then the proper Guix way to achieve the following:
>
> | All this came up in context of wanting to install '--system=i686-linux'
> | packages on '--system=x86_64-linux', and I'm not able to just
> | 'guix install --system=i686-linux gcc-toolchain@4.8.5' there.
> |
> | (Is there a fundamental reason for not allowing that, or just not yet
> | implemented?)
>
>
>> (For development, I’d also recommend ‘guix shell’ over ‘guix install’!)
>
> That's also what yelninei suggested on IRC.  I'm aware of 'guix shell',
> and 'guix shell --system=i686-linux [...]' does work as expected, but
> that's not feasible as an interactive shell if you'd like to use Guix GCC
> to build upstream GCC: see <https://debbugs.gnu.org/72669>
> "gcc-toolchain environment variables", for example.  I could have wrapper
> 'gcc' etc. scripts that internally do:
>
>     guix shell --system=i686-linux gcc-toolchain@4.8.5 -- gcc "$@"
>
> ..., but I'm not sure about the overhead of all those hundreds of
> 'guix shell [...]' invocations?

‘guix shell’ maintains a cache, which means that subsequent invocations
(cache hit) runs in ~100 ms:

--8<---------------cut here---------------start------------->8---
$ time guix shell -s i686-linux gcc-toolchain@4.8.5 -- gcc --version
gcc (GCC) 4.8.5
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


real    0m0.124s
user    0m0.131s
sys     0m0.025s
--8<---------------cut here---------------end--------------->8---

The overhead is small, but it might still be noticeable if you’re going
to run it hundreds of times.

Ideally, you would set up the entire development environment for GCC
with just a single ‘guix shell’ invocation and then go from here.  I
haven’t looked at the bug report you mention above and how that prevents
it from being practical, though.

HTH,
Ludo’.