kokkos icon indicating copy to clipboard operation
kokkos copied to clipboard

Create conda-forge package

Open mparno opened this issue 2 years ago • 2 comments

First off, thank you for developing Kokkos. It's a great package and has enabled us to make our monotone parameterization package, MParT, performance portable.

I was wondering if there were any plans to create a conda package for distributing Kokkos? Or if you knew of any technical reasons why this is not a good idea. Our team is working on constructing a conda-forge package for MParT and it would be nice to have Kokkos as a conda dependency instead of compiling it with our package.

We'd be happy to pull a Kokkos recipe (or more likely kokkos-cpu and kokkos-gpu recipes) together and submit it to conda-forge if this would be of broader interest to the Kokkos community.

mparno avatar Jul 25 '22 13:07 mparno

Hi,

I think we should talk about this, and what it takes to maintain this - because eventually questions regarding that package will come to use I fear :-).

Can you send an email to me and Damien so we can set something up?

Some initial thoughts: kokkos-cpu and kokkos-gpu itself doesn't seem to make too much sense to me, what does that mean? OpenMP, Threads, Serial? Cuda, HIP, SYCL? So we need to discuss stuff like what options should default and what would users need to explicit request etc. Maybe the right answer is kokkos-cuda, kokkos-openmp, kokkos-cuda-openmp etc. but I am not sure.

crtrott avatar Jul 25 '22 19:07 crtrott

@crtrott Email sent.

mparno avatar Jul 25 '22 21:07 mparno

We just started using the conda packages for Kokkos on linux and Mac. They seem to work well. We wanted to also use it for Windows. The current conda recipe skips windows and has the comment # Upstream does not build shared libs for Windows correctly. Indeed, I get a lot of missing symbols when linking against the dll as it doesn't appear any of the declspec dll export stuff is used. I compiled everything with -DCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS=TRUE and also did a couple of exports on static variables and then the dll seems to work, at least with the limited API calls we use.

For windows, we will probably only use threads and serial. Do you foresee any issues with using a shared library on windows? It doesn't seem like this is what is usually done...

brianmoose avatar Apr 20 '23 17:04 brianmoose

@brianmoose - were you able to create a conda-forge project and resolve the Windows issues? If not, what can we do to help further?

ajpowelsnl avatar Jul 31 '23 19:07 ajpowelsnl

We have been using the windows conda package as described above without any issues. We haven't put up the changes to upstream conda-forge as we have our own conda repository that we use that hosts it. I would be happy to create a PR on upstream if there is any interest.

brianmoose avatar Jul 31 '23 21:07 brianmoose

@brianmoose - thanks for your response, and glad to hear you've had success. @crtrott , @dalg24, should these changes be merged into conda-forge, proper?

ajpowelsnl avatar Jul 31 '23 21:07 ajpowelsnl