So, I’m working on a project that is implemented using SYCL, and eventually I would like for it to have Python bindings and will likely package that library for conda-forge.
An obvious dependency for this project would be one of the SYCL implementations. My plan is to make sure the library works with both AdaptiveCPP and DPC++ (open source LLVM version). I’ve been compiling these already for my dev containers and have been using conda-forge to provide dependent libraries and toolchains to make the future Python package deployment to conda-forge more seamless.
Recently I’ve been thinking it would be nice to have llvm sycl/AdaptiveCPP on conda-forge as well, even if I never get around to that Python package. Would this be something of interest? I’ve packaged for conda-forge before, but compiler toolchains are definitely far more complex.
AdaptiveCPP should be fairly straightforward, since it already has release versions and can be built using the already packaged llvm/clang toolchain on conda-forge.
DPC++, not so much. From what I’ve gathered, upstreaming the intel llvm sycl branch is in the works, but it’s not there yet. Instead, the sycl branch is just rebased on upstream frequently and everything is on a rolling develop branch. So, versioning here would be difficult. Not to mention, getting the latest features/fixes is probably best, but this means that the clang toolchain for the conda-forge package would be LLVM 19 (at the time of writing) which is way ahead the toolchain on conda-forge. However, llvm-sycl would need to forbid the already-present llvm/clang packages using run constraints as to avoid library/header clashes, so this might not be much of an issue?