[bug#49471] gnu: lld: Update to 12.0.0.

* gnu/packages/llvm.scm (llvm-subprojects-origin, %llvm-project-12.0.0-hash):
New variables.
(lld-11, lld-12): New variables.
(lld): Point to lld-11.
---
This patch is an alternative to the one sent by terramorpha.

Supposed advantages of it are:
* lld still points to lld-11, not breaking any packages that rely on it
* llvm-subprojects-origin can be reused by other LLVM subprojects
  (think of libcxx and libcxxabi, which both require each other, or
  libunwind, which requires libcxx)

Disadvantages are:
* llvm-project is a beefy tarball and somewhat of a pain to unpack
* Both this version and the original use an unclean approach to building
  subprojects, that is propagated by LLVM.  Perhaps we ought to instead
  clean up their mess?

Regards,
Leo

 gnu/packages/llvm.scm | 43 ++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 42 insertions(+), 1 deletion(-)

Hi,

Leo Prikler <leo.prikler@student.tugraz.at> skribis:

> * gnu/packages/llvm.scm (llvm-subprojects-origin, %llvm-project-12.0.0-hash):
> New variables.
> (lld-11, lld-12): New variables.
> (lld): Point to lld-11.
> ---
> This patch is an alternative to the one sent by terramorpha.
>
> Supposed advantages of it are:
> * lld still points to lld-11, not breaking any packages that rely on it
> * llvm-subprojects-origin can be reused by other LLVM subprojects
>   (think of libcxx and libcxxabi, which both require each other, or
>   libunwind, which requires libcxx)
>
> Disadvantages are:
> * llvm-project is a beefy tarball and somewhat of a pain to unpack
> * Both this version and the original use an unclean approach to building
>   subprojects, that is propagated by LLVM.  Perhaps we ought to instead
>   clean up their mess?

I’m not sure that the 2nd point means, but perhaps it can be addressed
separately?

> -(define-public lld
> +(define-public lld-11
>    (package
>      (name "lld")
>      (version "11.0.0")

Does it make sense to keep old versions of the linker around?  To me
it’s much less useful than keeping old versions of the compiler.

> +(define %llvm-project-12.0.0-hash "0a1n88dmbwp1ww7h3ykf0s001cndk1bm3i2cj1y2sh548f4nilcy")
                                     ^
I’d use ‘base32’ here (for expansion-time base32 decoding) and remove it
from ‘llvm-subprojects-origin’.

Otherwise LGTM.

Thanks!

Ludo’.

Hi,

Am Montag, den 19.07.2021, 19:37 +0200 schrieb Ludovic Courtès:
> Hi,
> 
> Leo Prikler <leo.prikler@student.tugraz.at> skribis:
> 
> > * gnu/packages/llvm.scm (llvm-subprojects-origin, %llvm-project-
> > 12.0.0-hash):
> > New variables.
> > (lld-11, lld-12): New variables.
> > (lld): Point to lld-11.
> > ---
> > This patch is an alternative to the one sent by terramorpha.
> > 
> > Supposed advantages of it are:
> > * lld still points to lld-11, not breaking any packages that rely
> > on it
> > * llvm-subprojects-origin can be reused by other LLVM subprojects
> >   (think of libcxx and libcxxabi, which both require each other, or
> >   libunwind, which requires libcxx)
> > 
> > Disadvantages are:
> > * llvm-project is a beefy tarball and somewhat of a pain to unpack
> > * Both this version and the original use an unclean approach to
> > building
> >   subprojects, that is propagated by LLVM.  Perhaps we ought to
> > instead
> >   clean up their mess?
> 
> I’m not sure that the 2nd point means, but perhaps it can be
> addressed separately?
The gist of it is that we can't build the projects from just their
source and "normal" inputs – we have to also unpack (or leave in the
source tree as done here) other sources, that would themselves
constitute different packages.

I'm not really sure how big of a problem that is in general (apart from
the annoyance of having to do that) – it simply feels unclean, that's
all I'm complaining about here.

> > -(define-public lld
> > +(define-public lld-11
> >    (package
> >      (name "lld")
> >      (version "11.0.0")
> 
> Does it make sense to keep old versions of the linker around?  To me
> it’s much less useful than keeping old versions of the compiler.

There don't seem to be dependants other than itself, but I didn't want
to accidentally break stuff, also concerning other channels.  Since
lld-12 will be used in the zig package thereafter, which takes
versioned LLVM as inputs, I think it's likely similar projects might
want to use lld 11 or older, which can be built by inheriting the
somewhat simpler lld-11 package.  (Similarly if you want zig 0.7 for
historical purposes, although that's entering Guix Past territory.)

> > +(define %llvm-project-12.0.0-hash
> > "0a1n88dmbwp1ww7h3ykf0s001cndk1bm3i2cj1y2sh548f4nilcy")
>                                      ^
> I’d use ‘base32’ here (for expansion-time base32 decoding) and remove
> it from ‘llvm-subprojects-origin’.
Point taken, I'll update that in v2.

Regards,
Leo