LLVM 17.0.6 #113
LLVM 17.0.6 #113
Conversation
h-vetinari
requested review from
isuruf,
katietz and
mingwandroid
as code owners
|
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
|
@h-vetinari |
|
That's why it has a little footnote. ;) |
This reverts commit fbf028c.
…nda-forge-pinning 2023.12.01.00.32.29
h-vetinari
force-pushed
the
17
branch
2 times, most recently
from
49805d2
to
8d8454e
Compare
There was a problem hiding this comment.
Given how slowly the {{ stdlib(...) }} discussion is progressing, I'm proposing to move forward here with a looser dependence on libcxx (this was suggested as an option by @isuruf in a core call a couple weeks ago).
PTAL @conda-forge/clang-compiler-activation
recipe/install-clang.sh
Outdated
| if [[ "${CBUILD}" != ${CHOST} ]]; then | ||
| if [[ "${CBUILD}" != ${CHOST} ]] && [[ "${target_platform}" != linux-* ]]; then | ||
| # on linux, the `clang` package already has a $TRIPLE-clang, see | ||
| # https://github.com/conda-forge/clangdev-feedstock/pull/251 | ||
| ln -s clang ${CBUILD}-clang |
There was a problem hiding this comment.
This adaptation is necessary for clang 16 & 17 post conda-forge/clangdev-feedstock#251 & 252, but fails for clang 15. It's also not consistent between platforms. AFAICT we have a few options:
- drop clang 15 here
- backport the sysroot-patch to clang 15
- make this branch version-dependent
- package
bin/${CBUILD}-clangintoclangalso on osx, and remove this branch entirely
Any preferences?
There was a problem hiding this comment.
@isuruf, could you please let me know your preferences for dealing with the new symlinks resp. the current differences between platforms & versions?
There was a problem hiding this comment.
Let's make the branch version dependent. That seems like the easiest.
There was a problem hiding this comment.
Fine by me. Long-term, what do you think about having the same symlink structure (across outputs) between linux and osx?
There was a problem hiding this comment.
Yeah, we should have the same structure if possible.
There was a problem hiding this comment.
OK. So if we want to unify this, currently we have:
| output | linux-* | osx-* |
|---|---|---|
gcc_impl_$target_platform |
bin/x86_64-conda-linux-gnu-cc...bin/x86_64-conda_cos6-linux-gnu-cc... |
- |
gcc_$target_platform |
.../activate-gcc_linux-64.sh.../deactivate-gcc_linux-64.sh |
- |
gcc |
bin/gcc |
- |
clang_impl_$target_platform |
- | bin/x86_64-apple-darwin13.4.0-clangor bin/arm64-apple-darwin20.0.0-clang |
clang_$target_platform |
- | .../activate_clang_osx-64.sh.../deactivate_clang_osx-64.sh |
clang |
bin/clangbin/x86_64-conda-linux-gnu-clang |
bin/clang |
Perhaps the cleaner approach would be to create an activation feedstock for clang on linux (or do it in this one?) and then have bin/x86_64-conda-linux-gnu-clang be under clang_impl_linux-64?
There was a problem hiding this comment.
Ping @isuruf. From the above, I'm guessing we could merge this as-is, and revisit the subject once we have clang_linux-* builds.
|
I'll open a follow-up issue for the harmonization. |
Blockers for merging this PR and thus enabling the compilers in conda-forge (indentation denotes dependency; c.f. list from 16.x):
Related feedstocks for LLVM 17 support more generally: