I pushed a few commits earlier when investigating why newer LLVM was unnecessarily being dragged in when emerging an older Clang slot: * 0cc229320a24ffa560d9fc101d4d73b03b7ce427 * dd78058fd574b3c012cdba0c58a326294dab3d79 * b060b90ece8a86ae4565795fac58627e4a3c0ce1 * 696f6219b94c6344e73aa6f850962752a1c07950 * d09b2cb36c5fa5e26543d529dd224de3df17d879 Anyway, it ended up letting me depclean LLVM 19 on one of my machines as nothing needed it yet. On another machine, I saw LLVM 19 being dragged in by media-libs/mesa and dev-util/intel_clc. * For media-libs/mesa, we have: """ [...] llvm? ( $(llvm_gen_dep " sys-devel/llvm:\${LLVM_SLOT}[llvm_targets_AMDGPU(+),${MULTILIB_USEDEP}] opencl? ( dev-util/spirv-llvm-translator:\${LLVM_SLOT} sys-devel/clang:\${LLVM_SLOT}[llvm_targets_AMDGPU(+),${MULTILIB_USEDEP}] ) ") video_cards_r600? ( virtual/libelf:0=[${MULTILIB_USEDEP}] ) video_cards_radeon? ( virtual/libelf:0=[${MULTILIB_USEDEP}] ) ) [...] opencl? ( >=virtual/opencl-3 dev-libs/libclc[spirv(-)] >=dev-util/spirv-tools-1.3.231.0 virtual/libelf:0= ) [...] """ Could we maybe fold things so that if we're in llvm? ( opencl? ( ... ) ), we include it in a llvm_gen_dep block, but not otherwise? Or maybe it's not worth it? I don't know if mesa and intel_clc use libclc as a library and actually need matching LLVM or not. (Note that libclc isn't slotted.) * For intel_clc, it's easier because we have: """ dev-libs/libclc dev-util/spirv-tools >=sys-libs/zlib-1.2.8:= x11-libs/libdrm $(llvm_gen_dep ' dev-util/spirv-llvm-translator:${LLVM_SLOT} sys-devel/clang:${LLVM_SLOT} sys-devel/llvm:${LLVM_SLOT} ') """ i.e. we're already bound by the (pesky) spirv-llvm-translator, so chucking in libclc there isn't going to be a problem with e.g. =dev-libs/libclc-${LLVM_SLOT}*. What do you think? I know it sounds a bit silly but I figured I'd bring it up given I'd come across it.
> Could we maybe fold things so that if we're in llvm? ( opencl? ( ... ) ), we > include it in a llvm_gen_dep block, but not otherwise? Or maybe it's not worth it? I think this is the request? Sorry, I've ready this bug a few times since it was filed and kept getting confused.
Let me figure out what I meant ;)
OK, I get it. * intel_clc We depend on "bare" llvm-core/libclc, while we depend on llvm_gen_dep'd other bits. The inconsistency there can mean Portage pulls in another slot of libclc when it could pack them together. We should consider putting them all in the llvm_gen_dep, even if not strictly necessary for the libclc dep. * mesa Similar deal but messier. We have `opencl? ( llvm-core/libclc[spirv(-)] )`, but if you have USE="llvm opencl", we could fold that in, at the cost of repeating ourselves for !llvm? ( ... ). We should consider grouping them in an llvm_gen_dep, even if it makes it a bit messier, as it'll avoid Portage pulling in another slot for libclc sometimes.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=17a56e6f868dc96f12e19177ed8c011c87bcbcda commit 17a56e6f868dc96f12e19177ed8c011c87bcbcda Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2025-01-04 20:02:53 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2025-01-04 20:03:36 +0000 media-libs/mesa: Version bump to 24.3.3 Bug: https://bugs.gentoo.org/940037 Signed-off-by: Matt Turner <mattst88@gentoo.org> media-libs/mesa/Manifest | 1 + media-libs/mesa/mesa-24.3.3.ebuild | 502 +++++++++++++++++++++++++++++++++++++ 2 files changed, 503 insertions(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7e61bbf42d49e15f6e9a180eedc30650f71d450c commit 7e61bbf42d49e15f6e9a180eedc30650f71d450c Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2025-01-04 20:02:19 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2025-01-04 20:03:36 +0000 media-libs/mesa: Add libclc dep inside llvm_gen_dep Bug: https://bugs.gentoo.org/940037 Signed-off-by: Matt Turner <mattst88@gentoo.org> media-libs/mesa/mesa-9999.ebuild | 1 + 1 file changed, 1 insertion(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3932788ec15c86707ac2d3efe66ea5cd9d29e6cd commit 3932788ec15c86707ac2d3efe66ea5cd9d29e6cd Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2025-01-04 19:57:22 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2025-01-04 20:03:36 +0000 dev-util/intel_clc: Version bump to 24.3.3 Bug: https://bugs.gentoo.org/940037 Signed-off-by: Matt Turner <mattst88@gentoo.org> dev-util/intel_clc/Manifest | 1 + dev-util/intel_clc/intel_clc-24.3.3.ebuild | 93 ++++++++++++++++++++++++++++++ 2 files changed, 94 insertions(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=690101171ed875d445f812448566786990e64155 commit 690101171ed875d445f812448566786990e64155 Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2025-01-04 19:55:05 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2025-01-04 20:03:36 +0000 dev-util/intel_clc: Move libclc dep inside llvm_gen_dep Bug: https://bugs.gentoo.org/940037 Signed-off-by: Matt Turner <mattst88@gentoo.org> dev-util/intel_clc/intel_clc-9999.ebuild | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
I've made these changes, but for Mesa I just *added* libclc to the llvm_gen_deps block and left the other libclc deps in place. I think this will have the desired effect, but with less churn. Looks okay to you?
Assuming this is okay. Please let me know if there are further improvements I can make.
