My understanding is that llvm upstream is written so that multiple versions can be installed at the same time, but we apply a number of patches that undo this ability. Is there some reason llvm isn't slotted? Thanks, William
Another question is why are we sub-slotting on the full ${PV} and not just MAJOR.MINOR which is the ABI layer. Do something like: ABI_VER="$(get_version_component_range 1-2)" SLOT="0/${ABI_VER}"
Or really better yet to achieve the goals of this bug. ABI_VER="$(get_version_component_range 1-2)" SLOT="${ABI_VER}"
(In reply to William Hubbs from comment #0) > My understanding is that llvm upstream is written so that multiple > versions can be installed at the same time, but we apply a number of > patches that undo this ability. > > Is there some reason llvm isn't slotted? I don't see where you deduce that from. I think LLVM used to be slotted in Gentoo, and that required patching and creating custom install layout specific to Gentoo (which in turn required patching packages). We certainly do not undo anything like that by patches. If you can do slotting sanely, I won't object a good ebuild patch. But I will object having to patch revdeps to work with Gentoo-specific invention. (In reply to Doug Goldstein from comment #1) > Another question is why are we sub-slotting on the full ${PV} and not just > MAJOR.MINOR which is the ABI layer. Do something like: > > ABI_VER="$(get_version_component_range 1-2)" > SLOT="0/${ABI_VER}" First of all, please do not mix issues. Secondly, please do not state what we're doing without checking it. We're subslotting on ABI. Which means subslot changes when ABI changes and SONAME changes appropriately. It happened in the past that upstream changed ABI along with third version component changes, and there's no rule for this. We're setting subslots as appropriate for each ebuild.
(In reply to Michał Górny from comment #3) > (In reply to William Hubbs from comment #0) > > My understanding is that llvm upstream is written so that multiple > > versions can be installed at the same time, but we apply a number of > > patches that undo this ability. > > > > Is there some reason llvm isn't slotted? > > I don't see where you deduce that from. I think LLVM used to be slotted in > Gentoo, and that required patching and creating custom install layout > specific to Gentoo (which in turn required patching packages). We certainly > do not undo anything like that by patches. > > If you can do slotting sanely, I won't object a good ebuild patch. But I > will object having to patch revdeps to work with Gentoo-specific invention. clang-0001-Install-clang-runtime-into-usr-lib-without-suffix.patch compiler-rt-0001-cmake-Install-compiler-rt-into-usr-lib-without-suffi.patch are some examples I've found. Building it locally from the tarball it seems to want to go into /usr/lib/llvm-MAJOR.MINOR by default so it would seem to me that we're doing some work to make this not a reality. > > (In reply to Doug Goldstein from comment #1) > > Another question is why are we sub-slotting on the full ${PV} and not just > > MAJOR.MINOR which is the ABI layer. Do something like: > > > > ABI_VER="$(get_version_component_range 1-2)" > > SLOT="0/${ABI_VER}" > > First of all, please do not mix issues. Secondly, please do not state what > we're doing without checking it. > > We're subslotting on ABI. Which means subslot changes when ABI changes and > SONAME changes appropriately. It happened in the past that upstream changed > ABI along with third version component changes, and there's no rule for > this. We're setting subslots as appropriate for each ebuild. http://llvm.org/releases/3.7.1/docs/ReleaseNotes.html#major-changes-in-3-7-1 I see the one off where 3.7.0 broke ABI but that seems like the exception and not the norm. 3.8.0 claims it'll keep ABI compatibility so I don't see why its got ${PV} as its subslot.
(In reply to Doug Goldstein from comment #4) > (In reply to Michał Górny from comment #3) > > (In reply to William Hubbs from comment #0) > > > My understanding is that llvm upstream is written so that multiple > > > versions can be installed at the same time, but we apply a number of > > > patches that undo this ability. > > > > > > Is there some reason llvm isn't slotted? > > > > I don't see where you deduce that from. I think LLVM used to be slotted in > > Gentoo, and that required patching and creating custom install layout > > specific to Gentoo (which in turn required patching packages). We certainly > > do not undo anything like that by patches. > > > > If you can do slotting sanely, I won't object a good ebuild patch. But I > > will object having to patch revdeps to work with Gentoo-specific invention. > > clang-0001-Install-clang-runtime-into-usr-lib-without-suffix.patch > compiler-rt-0001-cmake-Install-compiler-rt-into-usr-lib-without-suffi.patch > > are some examples I've found. Building it locally from the tarball it seems > to want to go into /usr/lib/llvm-MAJOR.MINOR by default so it would seem to > me that we're doing some work to make this not a reality. Read those patches again. As you should be able to see, the patches *keep* CLANG_VERSION, and remove only libdir suffix. Which makes it install to /usr/lib rather than /usr/lib64. It has nothing to do with versioning. Well, unless you're abusing LLVM_LIBDIR_SUFFIX. > > (In reply to Doug Goldstein from comment #1) > > > Another question is why are we sub-slotting on the full ${PV} and not just > > > MAJOR.MINOR which is the ABI layer. Do something like: > > > > > > ABI_VER="$(get_version_component_range 1-2)" > > > SLOT="0/${ABI_VER}" > > > > First of all, please do not mix issues. Secondly, please do not state what > > we're doing without checking it. > > > > We're subslotting on ABI. Which means subslot changes when ABI changes and > > SONAME changes appropriately. It happened in the past that upstream changed > > ABI along with third version component changes, and there's no rule for > > this. We're setting subslots as appropriate for each ebuild. > > http://llvm.org/releases/3.7.1/docs/ReleaseNotes.html#major-changes-in-3-7-1 > > I see the one off where 3.7.0 broke ABI but that seems like the exception > and not the norm. 3.8.0 claims it'll keep ABI compatibility so I don't see > why its got ${PV} as its subslot. I haven't installed that one yet. If it's SONAME is the same as 3.7, then it's a bug that should be reported. If it's not, then that's your answer.
There are older bugs talking about slotting llvm (for the history part). With autoconf builds, it was mostly not possible. Could be possible with cmake, but as we usually say "patches welcome". And that includes not breaking dependencies build (the usual suspect at the time was mesa). Also, for the SUBSLOT, yes 3.7.1 was an upstream mistake, but it did change the ABI. And 3.8.0 builds with a 3.8.0 SONAME
*** Bug 579762 has been marked as a duplicate of this bug. ***
It looks like the current ebuilds produce version suffixed libraries and binaries. The only real notable exception is /usr/include/{llvm,llvm-c,clang,clang-c}. I would think that if we version those directories, and patch dependant packages to use specific directories (I would hope that most of the cmake and configure scripts would have an option to specify llvm's header locations easily), then that might cover most of the issues. Beyond that, and eselect module to pick what /usr/bin/clang and /usr/bin/clang++ would be sweet as well. If there is need for help, I'd be happy to try to contribute. Though I might need a little guidance of what you guys need.
I'm working on this and it'll most likely land for 4.0.0 final. The main goal is to allow split LLVM upgrades without breaking clang in the process.
If someone wants to play with it before inclusion, I have a PR on GitHub. I'm going to commit it all for RC2 (this weekend, I suppose).
This is in place since 4.0.0. If someone wants 3.9 slotted, he'd need to submit a patch/PR updating it.
