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

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

[Ryan Prior via Guix-patches via]

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

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

[Ryan Prior via Guix-patches via]

* 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@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

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

[Ryan Prior via Guix-patches via]

* 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

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

[Ryan Prior via Guix-patches via]

* 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

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

[Ryan Prior via Guix-patches via]

* 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

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

[Ryan Prior via Guix-patches via]

* 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

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

[Ludovic Courtès]

Hi Ryan,

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

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

[Ryan Prior via Guix-patches via]

On Friday, May 22, 2020 9:42 AM, Ludovic Courtès <ludo@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

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

[Ludovic Courtès]

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