[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#43679] [PATCH 0/5] Add '--with-toolchain' package transformation op
From: |
zimoun |
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@gnu.org> wrote:
> From: Ludovic Courtès <ludovic.courtes@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@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