guix-patches
[Top][All Lists]
Advanced

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

[bug#41428] [PATCH 0/5] Wrappers for c compilers


From: Ryan Prior
Subject: [bug#41428] [PATCH 0/5] Wrappers for c compilers
Date: Fri, 22 May 2020 18:27:17 +0000

On Friday, May 22, 2020 9:42 AM, Ludovic Courtès <address@hidden> wrote:

> For packages, the workaround usually boils down to setting shell or Makefile 
> variable ‘CC’ to “gcc” or similar.

Agreed, packages have what they need already.

> As for users, they can have a shell alias.

At present, there's no way to specify a shell alias as part of an 
environment/profile manifest. These patches would fill that gap for this narrow 
use-case, as the `python-wrapper` package fills it for another narrow use case.

> it’s easily worked around

Fair.

> our guideline is to follow what upstream does, and none of these compilers 
> provides a ‘cc’ program. (There are
> threads in the mailing list archives discussing this.)

I find this persuasive locally, but in a global sense it results in a less 
compelling end-user experience which outweighs my partiality towards this 
guideline.


> I’m personally in favor of the status quo on this topic.

Thank you for weighing in!

My use-case, my vision, is that I want to provide end-users an environment 
manifest such that `guix environment -m build-env.scm` sets everything up so 
that `make && make check` succeed.

I created these wrappers in service of this vision, to save end-users the 
trouble of creating and managing aliases on a per-environment basis when they 
already don't have to do that using the working set they're familiar with. I 
want to position Guix as a total win for tooling simplicity; but a lot of small 
complexities, each of which is easily worked-around, add up quickly to 
undermine my message.

I would lose all interest in this patch set if I had a more general purpose way 
of extending a manifest with more things than just packages. I picture, for 
example, a manifest with three parts:

- packages
- env variables
- aliases

Right now afaict a manifest only has the first of those things. Given I've got 
this nice packagehammer, I'm inclined to insist upon the usefulness of this 
patch set as a means of turning `cc` into a nail.

But I'd be happier to use a better tool anyhow. What do y'all guix think is the 
best pattern to apply for my use case?


Sincerely,
Ryan





reply via email to

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