Hi,

A few years back I've slotted LLVM and Clang to make the life with
revdeps easier. Long story short, every major LLVM release (which
happens twice a year) breaks API and it takes some time for revdeps to
adjust. Slotting made it possible to install multiple versions
simultaneously, and therefore let "faster" packages use newer LLVM
without being blocked by "slower" packages on the user's system.

Unfortunately, this ended up pretty bothersome to maintain. Besides
making ebuilds quite complex (and prone to mistakes), I'm hearing more
and more reports of programs being broken through getting multiple LLVM versions in the link chain.

This is not something that can be easily solved. In other words, it's
a mess and I don't think we're really getting anywhere. For this
reason, I'm considering dropping slotting and going back to permitting
only a single version of LLVM and Clang being installed.

This would have two major implications:

1. If you installed any package that requires older LLVM, it'd block all
other packages from updating. If you hit two packages that do not have
a common supported LLVM version, you won't be able to install them
at all.

On the plus side, this will motivate developers to actually start fixing
these packages rather than letting them rot until I start removing old
LLVM versions.

2. We will no longer support having multiple clang versions installed.
While it was convenient for testing stuff, it's not really a killer
feature though.

The only real alternative I see is actively limiting supported LLVM
versions in packages to ensure that all libraries in the depgraph end up
using the same LLVM version. However, I don't think it's really worth
the effort.

I don't have a ready unslotting plan yet.

WDYT?

--
Best regards,
Michał Górny

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 08/11/2021 12.18, Michał Górny wrote:

WDYT?

I like slotted LLVM (and GCC) and always find it an advantage over other distributions where it is not so easy to install multiple versions of
LLVM (and GCC). It would be unfortunate to see this go. I also can not
remember when I last had problems with simultaneously installed LLVM
versions as a user.

Furthermore, un-slotting LLVM would mean that
dev-util/include-what-you-use (IWYU) users are bound to the LLVM version
used by IWYU. Which, in turn, means that they are also bound to the corresponding clang-tidy version. Sure, this is nothing that can not be
solved by manual user intervention, e.g., users manually installing a
newer clang-tidy version. But still, it would not be as easy and
convenient as before.

That said, I think it's mostly, if not wholly, up to the maintainer. And
since you already do a lot of Gentoo work, it may also be a win if we
reduce your LLVM workload.

- Flow

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This would stop other projects from working where they have their own
llvm port, cough rocm cough.

On 08/11/2021 11:18, Michał Górny wrote:

Hi,

A few years back I've slotted LLVM and Clang to make the life with
revdeps easier. Long story short, every major LLVM release (which
happens twice a year) breaks API and it takes some time for revdeps to adjust. Slotting made it possible to install multiple versions simultaneously, and therefore let "faster" packages use newer LLVM
without being blocked by "slower" packages on the user's system.

Unfortunately, this ended up pretty bothersome to maintain. Besides
making ebuilds quite complex (and prone to mistakes), I'm hearing more
and more reports of programs being broken through getting multiple LLVM versions in the link chain.

This is not something that can be easily solved. In other words, it's
a mess and I don't think we're really getting anywhere. For this
reason, I'm considering dropping slotting and going back to permitting
only a single version of LLVM and Clang being installed.

This would have two major implications:

1. If you installed any package that requires older LLVM, it'd block all other packages from updating. If you hit two packages that do not have
a common supported LLVM version, you won't be able to install them
at all.

On the plus side, this will motivate developers to actually start fixing these packages rather than letting them rot until I start removing old
LLVM versions.

2. We will no longer support having multiple clang versions installed.
While it was convenient for testing stuff, it's not really a killer
feature though.

The only real alternative I see is actively limiting supported LLVM
versions in packages to ensure that all libraries in the depgraph end up using the same LLVM version. However, I don't think it's really worth
the effort.

I don't have a ready unslotting plan yet.

WDYT?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Montag, 8. November 2021, 12:18:30 CET schrieb Michał Górny:

WDYT?

Not a Gentoo dev but a user who develops software.
I find it pretty convenient to have multiple LLVM versions available.
I'm developing software that links against LLVM and can test it against multiple versions pretty easy with the current setup. I can evaluate a
new LLVM version before switching my own software to it. I can even test
some old (already bit-rotted) software that needs an old LLVM version since Gentoo provides it.

I'm pretty sure that this argument also holds for all users that want to
test their software against multiple versions of Clang (just the same as it holds for slotted GCC).

To summarize: Slotted LLVM is not only a feature for other distribution packages but also for users of Gentoo that develop software in compiled languages.

I'm hearing more
and more reports of programs being broken through getting multiple LLVM versions in the link chain.

I'm actually experienced this, but slotted LLVM was a solution here not
a problem. Let me explain the link chain (an arrow means: "link against"):

my tool --> an unpackaged third party lib (bound to an old LLVM) -> LLVM 10
´-> graph-tool -> matplotlib -> Mesa (with AMD graphic card) -> LLVM 12 (system default)

So my tool depends on a third party lib which needs LLVM 10 (without an easy port).
But as I also have an AMD graphic card so my Mesa is compiled with libLLVM for AMDGPU
which loads LLVM 12. My tool uses graph-tool which at the end loads Mesa.
As a result my LLVM versions conflicted.

My fix was to modify the Mesa ebuild to use LLVM 10 as well. This would
have been possible without slotted LLVM, but then I has to use LLVM 10
for everything in my system. I'm also not sure, if this would
be possible on any other distribution (without containerizing stuff).
(In the meantime the third party lib has updated its code to LLVM 12 so everything is fine again.)

Best,
Gerion

-----BEGIN PGP SIGNATURE-----

iQGzBAABCAAdFiEEM/tVN9WpYYHnPZHxloeAdSYJHeoFAmGJHYIACgkQloeAdSYJ HeoeQwv9GzUazq3GtfMSyB2RDIlqTtHeYKzNcBVuph3Oc+3yM/0oROy7eqtnLzur YsrAii1tLWBzSKhCHUiRXDUUuuG2UbUG8B3M6B6fM11tTqas3Q9rHRlwD8J2QyC8 /YNoJx/Tmu4K8MuA+pCC3oIcEkMT//u2dz6YpCZUCKDwEirDBYhwvgjJ2XrZRYyQ LviqBXv+bAPl/S6mWnfBzNI9YqHKZ9OD3oIy/jFK8NZ71uKAZg1Qiien6IkbjGY5 3p00beKcsmGDhWcRQjetTJvLLkCAv3WJObxNgw7htZeZRraE9DQ/o/zMgCEgSncO a+cOFfzDrOFE/z+B8xcihqsdQylc66CQ2NkFctOoQAwWY1ZViZmGl8+8JnhoO/Zv DsgQTNHeveVtWYBqWa8Vqp4VaaZBw/KDYOZSKrS+B1MEDNmO77xZ0LaP14HZiHci 8iL+42dbqa9Vd5l4SRkC9N/zXeYct2fCW1cY/umQYyXEiZik1e19vdtGq66SRdkD
yInfWWgH
=STHk
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 08.11.2021 12:18, Michał Górny wrote:

Hi,

A few years back I've slotted LLVM and Clang to make the life with
revdeps easier. Long story short, every major LLVM release (which
happens twice a year) breaks API and it takes some time for revdeps to adjust. Slotting made it possible to install multiple versions simultaneously, and therefore let "faster" packages use newer LLVM
without being blocked by "slower" packages on the user's system.

Unfortunately, this ended up pretty bothersome to maintain. Besides
making ebuilds quite complex (and prone to mistakes), I'm hearing more
and more reports of programs being broken through getting multiple LLVM versions in the link chain.

This is not something that can be easily solved. In other words, it's
a mess and I don't think we're really getting anywhere. For this
reason, I'm considering dropping slotting and going back to permitting
only a single version of LLVM and Clang being installed.

This would have two major implications:

1. If you installed any package that requires older LLVM, it'd block all other packages from updating. If you hit two packages that do not have
a common supported LLVM version, you won't be able to install them
at all.

On the plus side, this will motivate developers to actually start fixing these packages rather than letting them rot until I start removing old
LLVM versions.

2. We will no longer support having multiple clang versions installed.
While it was convenient for testing stuff, it's not really a killer
feature though.

The only real alternative I see is actively limiting supported LLVM
versions in packages to ensure that all libraries in the depgraph end up using the same LLVM version. However, I don't think it's really worth
the effort.

I don't have a ready unslotting plan yet.

WDYT?

--
Best regards,
Michał Górny

This can block rust and consumers quite badly.
Currently in rust source ebuild we lock llvm version for system llvm to
exact one bundled by upstream, for example

1.55 - llvm12 (with/without system-llvm set)
1.56 - llvm13 (with/without system-llvm set)

that's effective with both system-llvm set or unset, and for rust-bin.
in theory I can unlock rust version and provide compatibility with
multiple, but we run into next problem:

rust-1.56 can come with llvm12 and llvm13, but only llvm13 if -system-llvm rust-bin only can use llvm13 (internal one, pre-compiled by upstream)

this will break firefox and spidermonkey and thunderbird on some
systems.
mozilla products need to be compiled and linked with the same llvm
version in all components.

compiling/linking firefox with llvm13/clang13, but rust-1.55 will
not be possible, because of mis-matched llvm versions. or it may work
but break at runtime.

and if we have multiple llvm possible in firefox it will not be able to
enforce dependency chain via portage.

well, we could introduce llvm-ver useflags for rust, and clang, so
firefox can require rust[llvm13(-)] clang[llvm13(-)] with a lot of
required-use boilerplate, but that's _very_ ugly.

--
Best regards,
Georgy

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, 9 November 2021 2:41:53 PM NZDT Sam James wrote:

On 8 Nov 2021, at 11:18, Michał Górny <mgorny@gentoo.org> wrote:
Hi,
A few years back I've slotted LLVM and Clang to make the life with
revdeps easier. Long story short, every major LLVM release (which
happens twice a year) breaks API and it takes some time for revdeps to adjust. Slotting made it possible to install multiple versions simultaneously, and therefore let "faster" packages use newer LLVM
without being blocked by "slower" packages on the user's system.

Unfortunately, this ended up pretty bothersome to maintain. Besides
making ebuilds quite complex (and prone to mistakes), I'm hearing more
and more reports of programs being broken through getting multiple LLVM versions in the link chain.

I think this might just be Blender and friends which are especially fragile.

We may be able to get away with just coordinating those together.

WDYT?

If we can help it, I'd really really prefer we don't. Being able to test various different various of Clang quickly (just like gcc) is really
helpful.

I agree. Personally, it's allowed me to narrow down a few bugs in programs/ test suites which only occur with specific LLVM/Clang versions. While I could just build the different versions locally, slotting in combination with package.env really has made testing easier.

(especially given one day, we might dare to dream of using Clang
for the system toolchain. It becomes a lot easier to check for
regressions if you can just flip the version.)

I'd love to see this one day :-)

Best,
sam

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE6TiHvKPfjLbCYrJRC091Pag9upAFAmGJ1lIACgkQC091Pag9 upCyIg//Us4mlQFjQtV2zFl/VRjzSPIQRClr3XDVbHpiMYXPDXHhbt2lCFVx4kuZ NCxfyr99uZxThDHwo5jU4XVyvBHMp1KwFdhvHlJQtASPyK5ZxAX3RafsRob6UFnc IrbpZKL8VrmPFbU6nQkbFivRwAGGzYxaqS405zetZ25GxoIf+l4/qhDMLxs1m5RE y/Jat58VaBt7SixF3bCdcGYwErPyEH2gqMSIMRShkvqSUca+TVKNtWKnSXg2VfD2 YpEWr1NYkG2T2BamVMVZN9g56ugSsEGgkhvV/98Wdc0ULhWINIOysTxv7da4b6Tt Ui8HOoTMzBuLngkfh2OmIq/J5EUC9typLd+kjrPIEhCf+xTDAseRNfEpH/g1GSXR U/0Hm/MtQTrUxd9s5UpFBPjaqx+c4xNzhXPCM/5jhC1zq0vnxyhBNHmTxGKa1604 Z3RuLkDPDA6FTYNqFc3MkpmlNA/GSGnhY9ydzJcNKeqGDpSxM6KHN3LWbXHi+pFZ h8Wk4tJ0/EHiGQ6/bjvl0sGQefAcQbJdaP8r+xw+53g9RkEaY39hMecVf7vEeS0z KXUXt26Y2Lrt1a3eF+t6ylEU3meUt/FC+2viKb/iEiRZkgvZ5QuAHwK+osaXVjqn TdcwhNo5DRarA5TaWu794N4xU2Rm1FqFeB4xROroVQVbjstsfiE=
=OObQ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8 Nov 2021, at 11:18, Michał Górny <mgorny@gentoo.org> wrote:
Hi,
A few years back I've slotted LLVM and Clang to make the life with
revdeps easier. Long story short, every major LLVM release (which
happens twice a year) breaks API and it takes some time for revdeps to adjust. Slotting made it possible to install multiple versions simultaneously, and therefore let "faster" packages use newer LLVM
without being blocked by "slower" packages on the user's system.

Unfortunately, this ended up pretty bothersome to maintain. Besides
making ebuilds quite complex (and prone to mistakes), I'm hearing more
and more reports of programs being broken through getting multiple LLVM versions in the link chain.

I think this might just be Blender and friends which are especially fragile.

We may be able to get away with just coordinating those together.

WDYT?

If we can help it, I'd really really prefer we don't. Being able to test various different various of Clang quickly (just like gcc) is really helpful.

(especially given one day, we might dare to dream of using Clang
for the system toolchain. It becomes a lot easier to check for
regressions if you can just flip the version.)

Best,
sam

-----BEGIN PGP SIGNATURE-----

iQGTBAEBCgB9FiEEYOpPv/uDUzOcqtTy9JIoEO6gSDsFAmGJ0eJfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDYw RUE0RkJGRkI4MzUzMzM5Q0FBRDRGMkY0OTIyODEwRUVBMDQ4M0IACgkQ9JIoEO6g SDuhpgf+K87CBpY89YXI1Ia3+5g5LnpPk3Z4TeFVINoxUCKc0e38JXHI4ACg6gr5 C0bnPXTkbEoQHQtA8cpriUbRFo+IwbvTjW6hms+zc+l8bCuzpRLvyCTuPVnreWEW zHWt4Lu2ogw8KnvVr33oC11ImFvjdWpfg9pSUvyyeWiBnUEDZviVLl7fib9lU2ae 3jxbLMLAFCBXR22HJjCF1MJsldh9IZecyscs0pdwDUkxX/5diw1YOQJgsu6QNSE2 zVO18UXs8p0nN7ZtIPYRg9vPWw/AfwKD7cnITZsEvOp6V3ZFPcqRvi+swLvFcTY1 zSpeE8sVBOakWNlCk4DJipwitQciFA==
=cOoD
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 2021-11-08 at 12:18 +0100, Michał Górny wrote:

Hi,

A few years back I've slotted LLVM and Clang to make the life with
revdeps easier. Long story short, every major LLVM release (which
happens twice a year) breaks API and it takes some time for revdeps to adjust. Slotting made it possible to install multiple versions simultaneously, and therefore let "faster" packages use newer LLVM
without being blocked by "slower" packages on the user's system.

Unfortunately, this ended up pretty bothersome to maintain. Besides
making ebuilds quite complex (and prone to mistakes), I'm hearing more
and more reports of programs being broken through getting multiple LLVM versions in the link chain.

This is not something that can be easily solved. In other words, it's
a mess and I don't think we're really getting anywhere. For this
reason, I'm considering dropping slotting and going back to permitting
only a single version of LLVM and Clang being installed.

This would have two major implications:

1. If you installed any package that requires older LLVM, it'd block all other packages from updating. If you hit two packages that do not have
a common supported LLVM version, you won't be able to install them
at all.

On the plus side, this will motivate developers to actually start fixing these packages rather than letting them rot until I start removing old
LLVM versions.

2. We will no longer support having multiple clang versions installed.
While it was convenient for testing stuff, it's not really a killer
feature though.

The only real alternative I see is actively limiting supported LLVM
versions in packages to ensure that all libraries in the depgraph end up using the same LLVM version. However, I don't think it's really worth
the effort.

I don't have a ready unslotting plan yet.

WDYT?

I've got the message and slotted LLVM and Clang are going to stay for
the time being.

--
Best regards,
Michał Górny

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

SGkgTWljaGHFgiwNCg0KTWljaGHFgiBHw7NybnkgPG1nb3JueUBnZW50b28ub3JnPiB3cml0ZXM6 DQoNCj4+IFsuLi5dDQo+Pg0KPj4gVW5mb3J0dW5hdGVseSwgdGhpcyBlbmRlZCB1cCBwcmV0dHkg Ym90aGVyc29tZSB0byBtYWludGFpbi4gIEJlc2lkZXMNCj4+IG1ha2luZyBlYnVpbGRzIHF1aXRl IGNvbXBsZXggKGFuZCBwcm9uZSB0byBtaXN0YWtlcyksIEknbSBoZWFyaW5nIG1vcmUNCj4+IGFu ZCBtb3JlIHJlcG9ydHMgb2YgcHJvZ3JhbXMgYmVpbmcgYnJva2VuIHRocm91Z2ggZ2V0dGluZyBt dWx0aXBsZSBMTFZNDQo+PiB2ZXJzaW9ucyBpbiB0aGUgbGluayBjaGFpbi4NCj4+IA0KPj4gVGhp cyBpcyBub3Qgc29tZXRoaW5nIHRoYXQgY2FuIGJlIGVhc2lseSBzb2x2ZWQuICBJbiBvdGhlciB3 b3JkcywgaXQncw0KPj4gYSBtZXNzIGFuZCBJIGRvbid0IHRoaW5rIHdlJ3JlIHJlYWxseSBnZXR0 aW5nIGFueXdoZXJlLiAgRm9yIHRoaXMNCj4+IHJlYXNvbiwgSSdtIGNvbnNpZGVyaW5nIGRyb3Bw aW5nIHNsb3R0aW5nIGFuZCBnb2luZyBiYWNrIHRvIHBlcm1pdHRpbmcNCj4+IG9ubHkgYSBzaW5n bGUgdmVyc2lvbiBvZiBMTFZNIGFuZCBDbGFuZyBiZWluZyBpbnN0YWxsZWQuDQo+PiANCj4+IFsu Li5dDQo+DQo+IEkndmUgZ290IHRoZSBtZXNzYWdlIGFuZCBzbG90dGVkIExMVk0gYW5kIENsYW5n IGFyZSBnb2luZyB0byBzdGF5IGZvcg0KPiB0aGUgdGltZSBiZWluZy4NCg0KVGhhbmsgeW91ISAg SSBhcHByZWNpYXRlIHlvdXIgZGVjaXNpb24uICBGcm9tIHRoZSBkaXNjdXNzaW9ucyBvZiB0aGlz DQp0aHJlYWQsIHRoZSBxdWFsaXR5IGFuZCBTTE9UaW5nIG9mIGxsdm0gaXMgYSBraWxsaW5nIGZl YXR1cmUgb2YgR2VudG9vLg0KDQpTaGFsbCB3ZSBvcGVuIGEgdHJhY2tlciBidWcgdG8gcHV0IHRv Z2V0aGVyIHRoZSBsaW5rYWdlIGJ1Z3M/ICBXZSBtaWdodA0KZ2FpbiBzb21lIGluc3BpcmF0aW9u cyBmcm9tIHRoZSBnbG9iYWwgcGljdHVyZS4NCg0KWW91cnMsDQpCZW5kYQ0K

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)