GNU bug report logs - #43679
[PATCH 0/5] Add '--with-toolchain' package transformation option

Previous Next

Full log

View this message in rfc822 format

From: zimoun <zimon.toutoune <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>, 43679 <at> debbugs.gnu.org
Cc: Ludovic Courtès <ludovic.courtes <at> inria.fr>
Subject: [bug#43679] [PATCH 0/5] Add '--with-toolchain' package transformation option
Date: Tue, 29 Sep 2020 12:44:55 +0200

Hi,

On Mon, 28 Sep 2020 at 21:53, Ludovic Courtès <ludo <at> gnu.org> wrote:
> From: Ludovic Courtès <ludovic.courtes <at> inria.fr>

> One thing I wasn’t entirely sure about: ‘--with-toolchain’ changes
> the toolchain of the specified package, not that of its dependents.
> This assumes that the toolchains all follow the same ABI.  This is
> the case for C, apparently, maybe not for C++.  Should it instead
> change to toolchain of the package’s dependents as well?
>
> Something like:
>
>   guix build guile --with-toolchain=guile <at> 3.0.4=clang-toolchain 
>
> generates working code.

Really cool!  Playing yesterday with the new ’package-mapping’ &
co. (checking ’package-with-explicit-ocaml’), a kind of new
’–with-toolchain’ option was my conclusion. :-)


However, ’–with-toolchain’ can be misleading since it is
’gnu-build-system’ and C/C++ software specific.  I mean, the patch #4
adding ’build-system-with-toolchain’ contains:

--8<---------------cut here---------------start------------->8---
+  (define toolchain-packages
+    ;; These are the GNU toolchain packages pulled in by GNU-BUILD-SYSTEM and
+    ;; all the build systems that inherit from it.  Keep the list in sync with
+    ;; 'standard-packages' in (guix build-system gnu).
+    '("gcc" "binutils" "libc" "libc:static" "ld-wrapper"))
+
+  (define (lower* . args)
+    (let ((lowered (apply lower args)))
+      (bag
+        (inherit lowered)
+        (build-inputs
+         (append (fold alist-delete
+                       (bag-build-inputs lowered)
+                       toolchain-packages)
+                 toolchain)))))
--8<---------------cut here---------------end--------------->8---

And for example, it will not remove ’default-ocaml’ and
’default-findlib’ in the ’ocaml-build-system’.  Even if it would be easy
to specify the options “–with-input=ocaml=ocaml-variant
–with-input=findlib=findlib-variant”.  But for the
’clojure-build-system’ it is 3 packages.

Another example a bit out-of-scope is to rebuild all the Emacs stack
using the package ’emacs-next’ instead of ’emacs’.  The
’emacs-build-system’ depends on ’emacs-minimal’ but some packages (see
’emacs-magit’) rewrite that using instead ’emacs-no-x’.  It could be
nice to be able to write:

  guix build -m manifest.m --with-toolchain=emacs-next-toolchain



In summary, does it make sense, either:

  - change the ’–with-toolchain’ to ’–with-gcc-toolchain’
or
  - tweak ’build-system-with-toolchain’ to pass ’toolchain-packages’ as
  parameter somehow and be able to run:
  
     guix build coq --with-toolchain=coq=ocaml-toolchain4.07
     
?     


> Another issue is that since we use ‘package-input-rewriting/spec’,
> we can’t change the toolchain of core packages like Guile or Perl
> without rebuilding the world.  For example, if we omit “@3.0.4”
> in the example above, we rebuild a “guile” package deep down and
> everything that follows (aka. “the world”).

Yeah but that’s maybe what people want: rebuild the world with another
toolchain, probably optimized for some specific machine (HPC cluster).


> Another option I considered was to graft the package that
> ‘--with-toolchain’ targets instead of rebuilding its dependents.
> Again that’d only work if the resulting binaries are ABI-compatible,
> but maybe that’s a reasonable assumption.  It would definitely save
> build time.  Should it be grafted, or should there be a separate
> option to do that?  Thoughts?

From my perspective, it should be another option.  For example, I
imagine people want to rebuild all the stack with Name-It© compiler.  Or
the Name-It© compiler could be not-ABI compatible.


All the best,
simon

Previous Next

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