[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#43679] [PATCH 0/5] Add '--with-toolchain' package transformation op
From: |
Ludovic Courtès |
Subject: |
[bug#43679] [PATCH 0/5] Add '--with-toolchain' package transformation option |
Date: |
Wed, 30 Sep 2020 10:46:29 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
Hi,
zimoun <zimon.toutoune@gmail.com> skribis:
> 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.
[...]
> 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:
>
> + (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)))))
Yeah this option is meant for C/C++ as I wrote above and (I think) in
the documentation.
> 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
Here you’d use ‘--with-input’, though package transformation options
have no effect when using a manifest.
> In summary, does it make sense, either:
>
> - change the ’–with-toolchain’ to ’–with-gcc-toolchain’
‘--with-gcc-toolchain=clang-toolchain’ would look strange. :-)
> - 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
Can’t you use ‘--with-input=ocamlX.Y=ocamlA.B’ in this case? If not, we
could devise a separate option rather than overload this one.
>> 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).
Yes, though it doesn’t necessarily make sense. :-)
But yeah, perhaps rebuilding everything above the given package would be
more in line with what people expect.
>> 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.
I’m not interested in proprietary compilers if that’s what you have in
mind. Besides, the SysV ABI is defined for C, so normally all C
compilers produce ABI-compatible code. There are exceptions such as
OpenMP (Clang is moving to their own libomp, I think, whereas GCC has
libgomp.)
Thanks for your feedback!
Ludo’.