[bug#64929] [PATCH] gnu: gcc-toolchain: Create a 'bin/cc' symlink.

[John Kehayias]

Hello,

On IRC Attila (I'm pretty sure) brought this to my attention. I don't
have much to add or feelings on this (I generally agree with the
reasoning for leaving out a cc link in gcc-toolchain directly) except:

On Mon, Aug 21, 2023 at 05:08 PM, Maxime Devos wrote:

> Op 21-08-2023 om 16:30 schreef Attila Lendvai:
>> ok, i see why this won't work.
>> CC=(cc-for-target) is fine for packages, but the use-case that i'd
>> like to facilitate is `guix shell gcc-toolchain some-other-deps` and
>> then build a project manually from the opened shell.
>> any ideas how to help/handle that use-case without disrupting
>> cross-compilation for packages?
>>
>
> IIUC, gcc-toolchain isn't used for "guix build" (I'm not really sure
> though), so if that's your use case, your current patch would work
> without problems w.r.t. cross-compilation.  Rhetorical question: why
> didn't I think of this when writing my previous message?
>
> However, (assuming my assumption about gcc-toolchain is correct),
> applying the patch would create a discrepancy between the build
> environment from "guix build/guix shell -D ..." and "guix shell
> gcc-toolchain more-deps", which isn't nice and is potentially
> confusing.
>
> I was going to suggest that the solution would be to modify your
> script to look for TARGET-cc when cross-compiling, but while that
> would be an improvement it wouldn't solve anything as Guix doesn't
> have TARGET-cc.
>
> For an alternate proposal (which I think has been proposed before, but
> I don't recall where), it might be possible to create 'symlink'
> packages "symlink-cc-gcc" and "symlink-cc-clang", that respectively
> have the cc->gcc and cc->clang symlink (also cc->clang should be
> removed from the clang package, otherwise there is a collision and a
> preference for clang).
>
> (I'm thinking of Debian's alternative system, but simplified (no
> priorities!) and based on packages.)
>

or something like our python-wrapper package. In other words, a package
to make things similar to other distros, just for a user that wants
their own environment like that.

Alternatively, I just wanted to note that in the --emulate-fhs option,
we do set up a 'cc' symlink, as part of "emulating" a more typical FHS
setup. I sort of just did that on my own since I thought it would be
useful for the times one wants the FHS shell. Anyway, that is an option,
though in a container you have to do more to set up your environment in
the first place.

John

> For --with-c-toolchain (*) (**) and the cross-compilation issue I
> mentioned, these should be forbidden for use in Guix packages (as in,
> "guix lint" doesn't like it/not accepted in Guix proper, if some other
> channel does it anyway, it's not recommended, but also not really any
> of Guix' concern).
>
> (*) I don't know if clang and cross-compilation is supported yet by
> --with-c-toolchain.
> (**) though with-c-toolchain isn't truly a concern, as it could simply
> adjust the symlink inputs ...
>
> (I have the impression that I previously was against such symlink
> packages, but I don't recall actually writing a message about it.)
>
> Best regards,
> Maxime Devos.