LLVM and Clang should be slottable because LLVM is used by Mesa and people might need specific versions of Clang for development, unrelated to the LLVM version required by Mesa. I will attach some patches that attempt to make sys-devel/llvm and sys-devel/clang slottable. There are also two new packages which will be used to manage the active LLVM and Clang versions: * app-admin/eselect-llvm * app-admin/eselect-clang It would be nice if people could test this and see if anything breaks. Right now you will need to unmerge the packages from SLOT="0" before installing any slotted versions because the patched ebuilds hard block sys-devel/{llvm,clang}:0. I'm not sure if a revbump will help portage realize that it can solve the block by upgrading. Some packages that depend on LLVM or Clang will probably also need their dependencies updated to specify a slot.
Created attachment 349238 [details, diff] add slots to sys-devel/llvm-2.8
Created attachment 349240 [details, diff] add slots to sys-devel/llvm-2.9
Created attachment 349242 [details, diff] add slots to sys-devel/llvm-3.0
Created attachment 349244 [details, diff] add slots to sys-devel/llvm-3.1
Created attachment 349246 [details, diff] add slots to sys-devel/llvm-3.2
Created attachment 349248 [details, diff] add slots to sys-devel/clang-2.8
Created attachment 349250 [details, diff] add slots to sys-devel/clang-2.9
Created attachment 349252 [details, diff] add slots to sys-devel/clang-3.0
Created attachment 349254 [details, diff] add slots to sys-devel/clang-3.1
Created attachment 349256 [details, diff] add slots to sys-devel/clang-3.2
Created attachment 349258 [details, diff] add slots to sys-devel/clang-9999
Created attachment 349260 [details, diff] add slots to sys-devel/llvm-2.9
Created attachment 349262 [details, diff] add slots to sys-devel/llvm-9999
Created attachment 349264 [details] app-admin/eselect-llvm ebuild
Created attachment 349266 [details] app-admin/eselect-llvm eselect module
Created attachment 349268 [details] app-admin/eselect-clang ebuild
Created attachment 349270 [details] app-admin/eselect-clang eselect module
Created attachment 349348 [details] app-admin/eselect-llvm eselect module
Did you test it? AFAICS mesa currently has trouble finding LLVM (it lacks -Wl,-rpath for some reason) and cmake doesn't install LLVM slotted like autotools do. I'm not sure how useful is the slotting at all. If it works, I'm not sure for how long it will. And it's definitely not something upstream would support.
Created attachment 353392 [details, diff] [PATCH] sys-devel/{llvm,clang}: Add SLOT support (v2) Michał Górny: Would you mind taking a look at this new patch? I'm currently using the radeon driver with live Mesa from the x11 overlay, and so far everything seems to be working fine.
We've talked a while on IRC and I'll now write a short summary of what I said so that it doesn't get lost in the chatter :). First of all, thanks for your effort. I see that you are working hard to get this done nicely, and I really appreciate that. Few notes now: 1. The most modern LLVM/clang ebuilds are in mgorny overlay right now. If we were to do this, we should start with those and see if it all fits nicely. 2. I don't think we're getting close to using CMake anytime soon but we should think about it as the future way of building LLVM & friends. Therefore, any solution that we undertake must not make switching to CMake much harder than it is without it. This especially involves the fact that CMake no longer uses 'llvm-X.Y' subdir of /usr/lib*, and that you'd need to modify the CMakefiles installed by LLVM and used by other projects. 3. I still think this is quite a custom thing, and not something that'd be supported upstream. We must be sure that maintaining it wouldn't cause a lot of unnecessary maintenance burden in the future, especially if we are to add future projects using LLVM which can require many fixes to get it all right. 4. To be honest, I hate eselect. I see a lot of added complexity here, including all the ebuild logic to get files split, eselect logic to support switching it all and ebuild/eclass logic to handle multiple LLVM slots somehow from other packages. Think of Boost and how it ended up... I think that're all the important points. Considering them all, the added complexity, the fact that it requires diverging from upstream and I feel like it will be actually used only by a few users, my opinion is not to proceed now. But that's just my opinion, and @voyageur has the last word. If we're to proceed, then we could sync this with the multilib ebuilds being committed to avoid requesting people to rebuild stuff twice. However, this will undoubtedly delay the multilib ebuilds a bit. If we're not to proceed, we can always revisit this later. Either when more users request it, or upstream makes this easier on us. In any case, I'd really appreciate if you could take at least part of this upstream and see what they think. I'd really like to know what are the odds, and if they could do something to make this easier. At the end, yet another random idea: can we use different --prefix to make this simpler? Something like installing the whole tree to /usr/lib/llvm-X.Y/{bin,lib*,share,...}, eselect just setting PATH and ld.so.conf paths, and llvm-config --prefix giving the right prefix. But that's just a random thought which needs a lot of work.
I doubt that we can actually cleanly support that. Using subdirectories for LLVM libraries has caused too much trouble so far (like broken parts of mesa).
*** Bug 545160 has been marked as a duplicate of this bug. ***
