Relationship between clangdev and libclang

[h-vetinari]

Currently clangdev hard-pins the libclang-output.

Since clang is the default compiler on osx, this makes it hard to compile against libclang (e.g. qt, resp. its reverse dependencies), because an unpinned host-dep on libclang will currently pick up a run-export of libclang >=15.0.6,<16, which can then not be installed on osx in a recipe that requires compilers, because we don't yet have clang 15 fully ready.

Since libclang has been abi-compatible since LLVM 13 (and we specifically have a libclang13 that libclang depends on), I guess we could loosen the dependence of clangdev on libclang to:

--- a/recipe/meta.yaml
+++ b/recipe/meta.yaml
@@ -95,7 +95,7 @@ outputs:
         - {{ pin_subpackage("clang", exact=True) }}
         - {{ pin_subpackage("clangxx", exact=True) }}
         - {{ pin_subpackage("clang-tools", exact=True) }}
-        - {{ pin_subpackage("libclang", exact=True) }}
+        - libclang{{ libclang_soversion }} >={{ version}}
         - {{ pin_subpackage("libclang-cpp", exact=True) }}
         - libcxx {{ cxx_compiler_version }}  # [osx]
         - llvmdev =={{ version }}

Thoughts @conda-forge/clangdev?

PS. Longterm we could perhaps include libclang in the global pinning like we do for numpy (i.e. use the oldest abi-compatible build for our current compilers). PPS. It's still not clear what will happen in upstream LLVM with the possibility to build (the equivalent of) libclang13. The original RFC got reverted for LLVM 15, and since it was very late in the release there's just an option to switch it back on, but that's not considered long-term stable. See thread & summary here, please join the discussion if you think knowing when libclang's ABI changes (esp. if less often than every major) is important.

[h-vetinari]

Since libclang has been abi-compatible since LLVM 13 [...]

Well, this turns out to be false, unfortunately: https://github.com/llvm/llvm-project/issues/60270

I guess we haven't seen any breakage yet, though this is the kind of risk we run unfortunately, seeing that what we're doing is not the default upstream anymore since LLVM 15 (and thus prone to faster bitrot).

CC @isuruf

[bonzini]

I guess we haven't seen any breakage yet, though this is the kind of risk we run unfortunately

Yeah, the breakage is subtle and unlikely to cause trouble outside a testsuite (I originally found it via KyleMayes/clang-rs#45), but it sucks nevertheless...