[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