Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slotted LLVM ebuilds #3717

Closed
wants to merge 31 commits into from
Closed

Slotted LLVM ebuilds #3717

wants to merge 31 commits into from

Conversation

mgorny
Copy link
Member

@mgorny mgorny commented Jan 29, 2017

  • split ebuilds for common stuff
  • slotted LLVM & clang packages
  • eclass to help building revdeps
  • (figured out &) update runtimes for slotting

The idea is rather simple. LLVM & clang packages are slotted, and are installed in /usr/lib/llvm/${SLOT} prefix. All bindirs are added to PATH via env.d in reverse version order, so newest LLVM is always preferred. An eclass will be provided to make it possible to easily use specific version in revdeps.

@mgorny mgorny added the work in progress The PR is not yet ready to be merged. label Jan 29, 2017
@gentoo-repo-qa-bot gentoo-repo-qa-bot added new package The PR is adding a new package. assigned PR successfully assigned to the package maintainer(s). labels Jan 29, 2017
@mgorny
Copy link
Member Author

mgorny commented Jan 29, 2017

CC @nigoro

@mgorny mgorny force-pushed the llvm-slotted branch 9 times, most recently from 5595686 to 0669038 Compare February 4, 2017 13:14
@mgorny mgorny removed assigned PR successfully assigned to the package maintainer(s). new package The PR is adding a new package. work in progress The PR is not yet ready to be merged. labels Feb 5, 2017
@gentoo-repo-qa-bot gentoo-repo-qa-bot added new package The PR is adding a new package. assigned PR successfully assigned to the package maintainer(s). labels Feb 5, 2017
@gentoo-repo-qa-bot
Copy link
Collaborator

Pull Request assignment

Areas affected: ebuilds, eclasses, profiles
Packages affected: app-vim/llvm-vim, dev-ml/llvm-ocaml, dev-python/clang-python, dev-util/lldb, media-libs/mesa...

app-vim/llvm-vim: @gentoo/proxy-maint (new package)
dev-ml/llvm-ocaml: @gentoo/llvm
dev-python/clang-python: @gentoo/proxy-maint (new package)
dev-util/lldb: @gentoo/llvm
media-libs/mesa: @gentoo/X11
sys-devel/clang: @gentoo/llvm
sys-devel/clang-runtime: @gentoo/llvm
sys-devel/lld: @gentoo/llvm
sys-devel/llvm: @gentoo/llvm
sys-devel/llvmgold: @gentoo/proxy-maint (new package)
sys-libs/compiler-rt: @gentoo/llvm
sys-libs/compiler-rt-sanitizers: @gentoo/llvm

@mgorny
Copy link
Member Author

mgorny commented Feb 5, 2017

So, good news everyone.

  1. The PATH based approach in eclass seems to be working just fine. I was able to build different versions of lldb, lld and mesa against appopriate LLVM slots. @gentoo/x11, please review the mesa dep changes. They're a bit crazy thanks to lack of version ranges.
  2. It seems that Portage treats weak blockers lazily, and somehow manages to avoid breaking everything in this crazy dep maze. Practically, this means that when using clang as system-wide compiler, it will build and install both llvm and clang before unmerging the previous llvm package (i.e. clang used to build stuff).

Introduce a slotted variant of compiler-rt libraries with the slot
matching the clang version. This will make it possible to install a new
compiler-rt version before upgrading clang to the corresponding version,
therefore preserving a working compiler through (even minor) clang
upgrades.

The alternative was to replace the complete version number with the
major version in the runtime directory path. However, software (e.g.
Mesa) hardcodes the default path and therefore breaks when it is
changed.
Allow any newer version of libcxx & libomp since both those libraries
are not slotted.
Support slotted LLVM versions correctly. Allow any version for 9999,
limit to <5 for 17.0.0_rc2 as current git does not work anymore.
For the older 13.0.4 branch, just force slot :0 since it does not
support 4.0 (the oldest slotted version).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
assigned PR successfully assigned to the package maintainer(s). do not merge Please DO NOT MERGE this PR. It will not be assigned but it will be scanned by CI. new package The PR is adding a new package.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants