[PATCH 0/5] Wrappers for c compilers

Done

Details

2 participants

Ludovic Courtès
Ryan Prior

Owner: unassigned

Submitted by: Ryan Prior

Severity: normal

Ryan Prior wrote on 21 May 2020 02:51

Recipients:(address . guix-patches@gnu.org)

Message-ID:20200521005046.19712-1-rprior@protonmail.com

As an end-user, I want to create a manifest that to hack on some code where
the upstream build system badly wants to use `cc' and provides no practical
way to avoid this. At present, I have to create symlinks myself or patch the
build system; either way is non-obvious to other people who might try and use
my manifest when I share it.

With this patch in Guix I can just specify `gcc-toolchain-wrapper' in my
manifest and have that be the end of it. For consistency's sake I have applied
this to all other c compilers I could find in Guix as well.

Ryan Prior (5):
  gnu: Add tcc-wrapper.
  gnu: Add pcc-wrapper.
  gnu: Add gcc-toolchain-wrapper.
  gnu: Add sdcc-wrapper.
  gnu: Add bcc-wrapper.

 gnu/packages/assembly.scm     |  3 +++
 gnu/packages/c.scm            | 32 ++++++++++++++++++++++++++++++++
 gnu/packages/commencement.scm |  3 +++
 gnu/packages/sdcc.scm         |  3 +++
 4 files changed, 41 insertions(+)

-- 
2.26.2

Ryan Prior wrote on 21 May 2020 02:57

[PATCH 2/5] gnu: Add pcc-wrapper.

Recipients:(address . 41428@debbugs.gnu.org)

Message-ID:20200521005700.19948-2-rprior@protonmail.com

* gnu/packages/c.scm (pcc-wrapper): New variable.

---

gnu/packages/c.scm | 1 +

1 file changed, 1 insertion(+)

Toggle diff (11 lines)diff --git a/gnu/packages/c.scm b/gnu/packages/c.scm
index 757cfa7fba..e83a1d5c61 100644
--- a/gnu/packages/c.scm
+++ b/gnu/packages/c.scm
@@ -319,3 +319,4 @@ releases.")
 under the name @command{cc}.")))))
 
 (define-public tcc-wrapper (wrap-cc tcc))
+(define-public pcc-wrapper (wrap-cc pcc))
-- 
2.26.2

Ryan Prior wrote on 21 May 2020 02:57

[PATCH 1/5] gnu: Add tcc-wrapper.

Recipients:(address . 41428@debbugs.gnu.org)

Message-ID:20200521005700.19948-1-rprior@protonmail.com

* gnu/packages/c.scm (tcc-wrapper): New variable.
* gnu/packages/c.scm (wrap-cc): New variable.
---
 gnu/packages/c.scm | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

Toggle diff (48 lines)diff --git a/gnu/packages/c.scm b/gnu/packages/c.scm
index 5718ec66ac..757cfa7fba 100644
--- a/gnu/packages/c.scm
+++ b/gnu/packages/c.scm
@@ -7,6 +7,7 @@
 ;;; Copyright © 2019 Guillaume Le Vaillant <glv@posteo.net>
 ;;; Copyright © 2019 Andreas Enge <andreas@enge.fr>
 ;;; Copyright © 2020 Jan (janneke) Nieuwenhuizen <janneke@gnu.org>
+;;; Copyright © 2020 Ryan Prior <rprior@protonmail.com>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -288,3 +289,33 @@ address space pointers point to, or what locks a function acquires or
 releases.")
     (home-page "https://sparse.wiki.kernel.org/index.php/Main_Page")
     (license license:expat)))
+
+(define-public wrap-cc
+  (lambda* (cc #:optional
+               (bin (package-name cc))
+               (name (string-append (package-name cc) "-wrapper")))
+    (package/inherit cc
+      (name name)
+      (source #f)
+      (build-system trivial-build-system)
+      (outputs '("out"))
+      (native-inputs '())
+      (inputs '())
+      (propagated-inputs `(("cc" ,cc)))
+      (arguments
+       `(#:modules ((guix build utils))
+         #:builder
+         (begin
+           (use-modules (guix build utils))
+           (let ((bin-dir (string-append (assoc-ref %build-inputs "cc") "/bin/"))
+                 (wrapper-dir (string-append (assoc-ref %outputs "out") "/bin/")))
+             (mkdir-p wrapper-dir)
+             (symlink (string-append bin-dir ,bin)
+                      (string-append wrapper-dir "cc"))))))
+      (synopsis (string-append "Wrapper for " bin))
+      (description
+       (string-append
+        "Wraps " (package-name cc) " such that @command{" bin "} can be invoked
+under the name @command{cc}.")))))
+
+(define-public tcc-wrapper (wrap-cc tcc))
-- 
2.26.2

Ryan Prior wrote on 21 May 2020 02:57

[PATCH 3/5] gnu: Add gcc-toolchain-wrapper.

Recipients:(address . 41428@debbugs.gnu.org)

Message-ID:20200521005700.19948-3-rprior@protonmail.com

* gnu/packages/commencement.scm (gcc-toolchain-wrapper): New variable.

---

gnu/packages/commencement.scm | 3 +++

1 file changed, 3 insertions(+)

Toggle diff (16 lines)diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index 59ef5d078b..e6ef3c301c 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -3870,6 +3870,9 @@ binaries, plus debugging symbols in the @code{debug} output), and Binutils.")
 (define-public gcc-toolchain
   (make-gcc-toolchain gcc-final))
 
+(define-public gcc-toolchain-wrapper
+  (wrap-cc gcc-toolchain "gcc"))
+
 (define-public gcc-toolchain-4.8
   (make-gcc-toolchain gcc-4.8))
 
-- 
2.26.2

Ryan Prior wrote on 21 May 2020 02:57

[PATCH 4/5] gnu: Add sdcc-wrapper.

Recipients:(address . 41428@debbugs.gnu.org)

Message-ID:20200521005700.19948-4-rprior@protonmail.com

* gnu/packages/sdcc.scm (sdcc-wrapper): New variable.

---

gnu/packages/sdcc.scm | 3 +++

1 file changed, 3 insertions(+)

Toggle diff (20 lines)diff --git a/gnu/packages/sdcc.scm b/gnu/packages/sdcc.scm
index 6d05470101..a95ef2ac0f 100644
--- a/gnu/packages/sdcc.scm
+++ b/gnu/packages/sdcc.scm
@@ -20,6 +20,7 @@
 (define-module (gnu packages sdcc)
   #:use-module (gnu packages bison)
   #:use-module (gnu packages boost)
+  #:use-module (gnu packages c)
   #:use-module (gnu packages flex)
   #:use-module (gnu packages python)
   #:use-module (gnu packages texinfo)
@@ -68,3 +69,5 @@ HC08-based (hc08, s08), Zilog Z80-based MCUs (z80, z180, gbz80, Rabbit
 Work is in progress on supporting the Microchip PIC16 and PIC18 targets.
 It can be retargeted for other microprocessors.")
     (license license:gpl2+)))
+
+(define-public sdcc-wrapper (wrap-cc sdcc))
-- 
2.26.2

Ryan Prior wrote on 21 May 2020 02:57

[PATCH 5/5] gnu: Add bcc-wrapper.

Recipients:(address . 41428@debbugs.gnu.org)

Message-ID:20200521005700.19948-5-rprior@protonmail.com

* gnu/packages/assembly.scm (bcc-wrapper): New variable.

---

gnu/packages/assembly.scm | 3 +++

1 file changed, 3 insertions(+)

Toggle diff (23 lines)diff --git a/gnu/packages/assembly.scm b/gnu/packages/assembly.scm
index c775603445..a8fe135ded 100644
--- a/gnu/packages/assembly.scm
+++ b/gnu/packages/assembly.scm
@@ -36,6 +36,7 @@
   #:use-module (gnu packages autotools)
   #:use-module (gnu packages base)
   #:use-module (gnu packages bison)
+  #:use-module (gnu packages c)
   #:use-module (gnu packages compression)
   #:use-module (gnu packages flex)
   #:use-module (gnu packages gettext)
@@ -223,6 +224,8 @@ assembler, a C compiler and a linker.  The assembler uses Intel syntax
     (supported-systems '("i686-linux" "x86_64-linux"))
     (license license:gpl2+)))
 
+(define-public bcc-wrapper (wrap-cc dev86 "bcc" "bcc-wrapper"))
+
 (define-public libjit
   (let ((commit "554c9f5c750daa6e13a6a5cd416873c81c7b8226"))
     (package
-- 
2.26.2

Ludovic Courtès wrote on 22 May 2020 11:42

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

Recipients:(name . Ryan Prior)(address . rprior@protonmail.com)(address . 41428@debbugs.gnu.org)

Message-ID:87d06wb916.fsf@gnu.org

Hi Ryan,

Ryan Prior <rprior@protonmail.com> skribis:

Toggle quote (10 lines)> As an end-user, I want to create a manifest that to hack on some code where
> the upstream build system badly wants to use `cc' and provides no practical
> way to avoid this. At present, I have to create symlinks myself or patch the
> build system; either way is non-obvious to other people who might try and use
> my manifest when I share it.
>
> With this patch in Guix I can just specify `gcc-toolchain-wrapper' in my
> manifest and have that be the end of it. For consistency's sake I have applied
> this to all other c compilers I could find in Guix as well.

A long time ago, we decided against it, which is not to say that this is

set in stone but at least there’s a discussion to be had. :-)

For packages, the workaround usually boils down to setting shell or

Makefile variable ‘CC’ to “gcc” or similar. As for users, they can have

a shell alias.

In a nutshell, the reasons to not have a ‘cc’ program are that (1) it’s

easily worked around, and (2) 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’m personally in favor of the status quo on this topic.

Thoughts?

Thanks,

Ludo’.

Ryan Prior wrote on 22 May 2020 20:27

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 41428@debbugs.gnu.org)

Message-ID:IZgKyGkRb54dx__3SuILXblARLA5eBSphJSQxImJIxDVsV5PiTcMDij6Qdseefuc9vh_r0CCAvgv8nfJKNnjCcJF5Zm2v8WTcHeGfkHW_rY=@protonmail.com

On Friday, May 22, 2020 9:42 AM, Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (2 lines)

> 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.

Toggle quote (2 lines)

> 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.

Toggle quote (2 lines)

> it’s easily worked around

Fair.

Toggle quote (3 lines)

> 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.

Toggle quote (2 lines)

> 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

Ludovic Courtès wrote on 27 May 2020 23:01

Recipients:(name . Ryan Prior)(address . rprior@protonmail.com)(address . 41428@debbugs.gnu.org)

Message-ID:875zchhz22.fsf@gnu.org

Hi,

Ryan Prior <rprior@protonmail.com> skribis:

Toggle quote (12 lines)> 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’.

Ludovic Courtès wrote on 12 Jun 2020 18:12

control message for bug #41428

Recipients:(address . control@debbugs.gnu.org)

Message-ID:87a7185kld.fsf@gnu.org

tags 41428 wontfix
close 41428
quit

Your comment

This issue is archived.

To comment on this conversation send an email to 41428@debbugs.gnu.org

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date