GNU bug report logs - #41428
[PATCH 0/5] Wrappers for c compilers

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 41428 in the body.
You can then email your comments to 41428 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ryan Prior <rprior <at> protonmail.com>
To: guix-patches <at> gnu.org
Subject: [PATCH 0/5] Wrappers for c compilers
Date: Thu, 21 May 2020 00:51:00 +0000

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

Message #8 received at 41428 <at> debbugs.gnu.org (full text, mbox):

From: Ryan Prior <rprior <at> protonmail.com>
To: 41428 <at> debbugs.gnu.org
Subject: [PATCH 2/5] gnu: Add pcc-wrapper.
Date: Thu, 21 May 2020 00:57:26 +0000

* gnu/packages/c.scm (pcc-wrapper): New variable.
---
 gnu/packages/c.scm | 1 +
 1 file changed, 1 insertion(+)

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

Message #11 received at 41428 <at> debbugs.gnu.org (full text, mbox):

From: Ryan Prior <rprior <at> protonmail.com>
To: 41428 <at> debbugs.gnu.org
Subject: [PATCH 1/5] gnu: Add tcc-wrapper.
Date: Thu, 21 May 2020 00:57:20 +0000

* 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(+)

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 <at> posteo.net>
 ;;; Copyright © 2019 Andreas Enge <andreas <at> enge.fr>
 ;;; Copyright © 2020 Jan (janneke) Nieuwenhuizen <janneke <at> gnu.org>
+;;; Copyright © 2020 Ryan Prior <rprior <at> 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

Message #14 received at 41428 <at> debbugs.gnu.org (full text, mbox):

From: Ryan Prior <rprior <at> protonmail.com>
To: 41428 <at> debbugs.gnu.org
Subject: [PATCH 3/5] gnu: Add gcc-toolchain-wrapper.
Date: Thu, 21 May 2020 00:57:30 +0000

* gnu/packages/commencement.scm (gcc-toolchain-wrapper): New variable.
---
 gnu/packages/commencement.scm | 3 +++
 1 file changed, 3 insertions(+)

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

Message #17 received at 41428 <at> debbugs.gnu.org (full text, mbox):

From: Ryan Prior <rprior <at> protonmail.com>
To: 41428 <at> debbugs.gnu.org
Subject: [PATCH 4/5] gnu: Add sdcc-wrapper.
Date: Thu, 21 May 2020 00:57:36 +0000

* gnu/packages/sdcc.scm (sdcc-wrapper): New variable.
---
 gnu/packages/sdcc.scm | 3 +++
 1 file changed, 3 insertions(+)

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

Message #20 received at 41428 <at> debbugs.gnu.org (full text, mbox):

From: Ryan Prior <rprior <at> protonmail.com>
To: 41428 <at> debbugs.gnu.org
Subject: [PATCH 5/5] gnu: Add bcc-wrapper.
Date: Thu, 21 May 2020 00:57:39 +0000

* gnu/packages/assembly.scm (bcc-wrapper): New variable.
---
 gnu/packages/assembly.scm | 3 +++
 1 file changed, 3 insertions(+)

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

Message #23 received at 41428 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Ryan Prior <rprior <at> protonmail.com>
Cc: 41428 <at> debbugs.gnu.org
Subject: Re: [bug#41428] [PATCH 0/5] Wrappers for c compilers
Date: Fri, 22 May 2020 11:42:29 +0200

Hi Ryan,

Ryan Prior <rprior <at> protonmail.com> skribis:

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

Message #26 received at 41428 <at> debbugs.gnu.org (full text, mbox):

From: Ryan Prior <rprior <at> protonmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 41428 <at> debbugs.gnu.org
Subject: Re: [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 <ludo <at> gnu.org> 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

Message #29 received at 41428 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Ryan Prior <rprior <at> protonmail.com>
Cc: 41428 <at> debbugs.gnu.org
Subject: Re: [bug#41428] [PATCH 0/5] Wrappers for c compilers
Date: Wed, 27 May 2020 23:01:57 +0200

Hi,

Ryan Prior <rprior <at> 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’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.