From: "Ludovic Courtès" <ludo@gnu.org>
To: Ryan Prior <rprior@protonmail.com>
Cc: 41428@debbugs.gnu.org
Subject: [bug#41428] [PATCH 0/5] Wrappers for c compilers
Date: Wed, 27 May 2020 23:01:57 +0200 [thread overview]
Message-ID: <875zchhz22.fsf@gnu.org> (raw)
In-Reply-To: <IZgKyGkRb54dx__3SuILXblARLA5eBSphJSQxImJIxDVsV5PiTcMDij6Qdseefuc9vh_r0CCAvgv8nfJKNnjCcJF5Zm2v8WTcHeGfkHW_rY=@protonmail.com> (Ryan Prior's message of "Fri, 22 May 2020 18:27:17 +0000")
Hi,
Ryan Prior <rprior@protonmail.com> skribis:
> 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.
I understand your goal and I agree that it’s good to avoid building a
pile of small complexities that all add up.
I don’t think lack of ‘cc’ is one them though. First, because it’s a
developer tool, and developers will know they can type ‘gcc’, ‘clang’,
or whatever, create an alias, etc. Second, because most build systems
(Autoconf-generated ‘configure’ scripts, CMake) accommodate the lack of
‘cc’, which thus goes unnoticed.
My 2¢!
Ludo’.
prev parent reply other threads:[~2020-05-27 21:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-21 0:51 [bug#41428] [PATCH 0/5] Wrappers for c compilers Ryan Prior via Guix-patches via
2020-05-21 0:57 ` [bug#41428] [PATCH 1/5] gnu: Add tcc-wrapper Ryan Prior via Guix-patches via
2020-05-21 0:57 ` [bug#41428] [PATCH 2/5] gnu: Add pcc-wrapper Ryan Prior via Guix-patches via
2020-05-21 0:57 ` [bug#41428] [PATCH 3/5] gnu: Add gcc-toolchain-wrapper Ryan Prior via Guix-patches via
2020-05-21 0:57 ` [bug#41428] [PATCH 4/5] gnu: Add sdcc-wrapper Ryan Prior via Guix-patches via
2020-05-21 0:57 ` [bug#41428] [PATCH 5/5] gnu: Add bcc-wrapper Ryan Prior via Guix-patches via
2020-05-22 9:42 ` [bug#41428] [PATCH 0/5] Wrappers for c compilers Ludovic Courtès
2020-05-22 18:27 ` Ryan Prior via Guix-patches via
2020-05-27 21:01 ` Ludovic Courtès [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875zchhz22.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=41428@debbugs.gnu.org \
--cc=rprior@protonmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).