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

["Ludovic Courtès" <ludovic.courtes@inria.fr>]

zimoun <zimon.toutoune@gmail.com> skribis:

> On Wed, 30 Sep 2020 at 10:46, Ludovic Courtès <ludovic.courtes@inria.fr> wrote:
>
>> > 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:
>
> [...]
>
>> Yeah this option is meant for C/C++ as I wrote above and (I think) in
>> the documentation.
>
> Yes in the manual, not in the command line helper.
>
> Without bikeshedding, I find '--with-toolchain' a bad name since it is
> only 'gnu-build-system' related.  And from my point of view, it is
> also a bad name for the procedures 'build-system-with-toolchain' and
> 'package-with-toolchain' -- but it does not matter since they are not
> written in stone, contrary to command line options harder to change.

I agree that C/C++ don’t have a monopoly on tool chains, no argument
here.  The term “tool chain” is widely used for C/C++ though, much less
for other languages (often the “tool chain” is a single package for
other languages).

We could change the name to ‘--with-c-toolchain’ maybe?  Then someone
might come and suggest that this doesn’t account for C++, Objective-C,
and FORTRAN.

>> 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.
>
> No, in this case one should use:
>
>    guix build coq \
>           --with-input=ocaml=ocaml@4.07 \
>           --with-input=ocaml-findlib=ocaml4.07-findlib

Hmm I think the second one is unnecessary since
‘--with-input=ocaml=ocaml@4.07’ effectively gives an ‘ocaml-findlib’
built against OCaml 4.07.

Anyway, we’re drifting off-topic; let’s address OCaml separately if
something needs to be addressed.

> For consistency, it appears to me easier to have one "toolchain" per
> build system, say ocaml-toolchain, gcc-toolchain, haskell-toolchain,
> and then provides this toolchain to the option '--with-toolchain'.
> However, it is complicated to remove the 'build-inputs' since they are
> not hard coded -- as it is the case in 'build-system-with-toolchain'.
> Or another option is to have one command line option per build system:
> --with-gnu-toolchain, --with-ocaml-toolchain, --with-cargo-toolchain,
> etc..

If there’s a need for that, yes.  We’ll see!

>> 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.)
>
> It was what I have in mind. :-)
> But do the exceptions you point not imply another option?

We can’t completely prevent people from shooting themselves in the foot
with transformations, but yeah, maybe we should rebuild everything
higher in the stack with the same toolchain.

Thanks,
Ludo’.