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

[zimoun]

Hi,

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.


> >   - change the ’–with-toolchain’ to ’–with-gcc-toolchain’
>
> ‘--with-gcc-toolchain=clang-toolchain’ would look strange.  :-)

Why not? :-)
My point is: '--with-toolchain' is not specific enough.  Maybe
'--with-gnu-toolchain'?


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

No, in this case one should use:

   guix build coq \
          --with-input=ocaml=ocaml@4.07 \
          --with-input=ocaml-findlib=ocaml4.07-findlib

to recompile the package 'coq' with the 4.07 'ocaml-build-system'.
For the 'clojure-build-system', there are 3 inputs to specify.  (I
have not checked all the build systems :-)).  And note it works only
if the tools used by the build system are not hidden.

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


> > 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.  :-)

Sadly!

> But yeah, perhaps rebuilding everything above the given package would be
> more in line with what people expect.

Yeah...maybe providing "what people expect" could reduce the gap in
the HPC community.


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

It was what I have in mind. :-)
But do the exceptions you point not imply another option?

All the best,
simon