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

[Ludovic Courtès]

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