Should Conan package manager support be dropped from this oneMKL Interfaces project?

[vmalia]

Background

Conan C++ Package Manager is a convenient automation tool to download, install and set up build and runtime dependencies for this oneMKL Interfaces project.

Changes since the initial implementation

1. Netlib Conan package for BLAS and LAPACK is no longer maintained on the official Conan center (Conan package repository): https://conan.io/center
2. Conan supports Intel DPC++ Compiler and Intel LLVM XMain compiler out-of-the-box.

Things to consider when responding to the poll

1. Complexity and convenience of using Conan versus manual installation methods for each dependency required for your use-case. For example, if your use-case requires CUDA, you will need to install CUDA, Netlib (for functional testing), Intel LLVM Compiler, CMake, make/ninja-build individually using their own installation methods and setup the environment before building oneMKL Interfaces project.
2. A use-case to try different backends. Usually, the end-user of this project will end up using at most 2 backends (Netlib + GPU backend) because most GPU backends currently supported by this project are vendor-specific (CUDA for Nvidia, RoC for AMD, etc). oneAPI is an exception because it can support non-Intel vendors through the DPC++ Compatibility Tool

Note: Currently, Conan support is broken in the oneMKL-Interfaces project due to absence of Netlib package and out-of-date recipe.

Poll timeline

Poll ends on April 30, 2023.
Result analysis and decision will be posted tentatively by the end of July 2023.

[Sholde]

I only use cmake but I don't want to force the conan drop just because I don't use it.

[mmeterel]

I never tried using Conan in this project. Does it currently work for all/some/any backends? If not, what is the effort needed to make it functional?

[vmalia]

Good question!
We currently only support oneMKL backend.
To enable other backends, we need to create a conan recipe that downloads the backend and creates a package from it. We will also have to maintain that recipe and keep it updated whenever a breaking change happens on the backend install instructions.

The recipe can be shipped in the github repo itself, so we can avoid hosting the packages on a remote server.

As an estimate, I would say 1-2 days to develop the recipe for each backend. Maintenance effort is hard to estimate in the long term. The hope is that it will be minimal if we have a CI that regularly builds the project using Conan commands.

[mmeterel]

Thanks for your feedback. Based on your answer, I would vote to remove something that is not currently fully working. (Even though I can get oneMKL backend using Conan, I cannot test it without Netlib). Removing it will also clarify/simplify the build directions. When/If there is request, we can consider adding it back with (hopefully) full capability.

[zjin-lcf]

I have a question: could the oneMKL interface be built at the same time when people build the DPC++ compiler with CUDA/HIP support using the configure/compile scripts (configure.py and compile.py) ?

[vmalia]

@zjin-lcf I don't think this is currently supported, but it sounds like a good use case to consider. Thank you!

[vmalia]

Since the voting results have been 50-50, our team has decided to drop Conan package manager support in light of the increased effort required to support it at this time.

[Croydon]

conan-io/conan-center-index#4509
conan-io/conan-center-index#23364

[vmalia]

Thank you @Croydon for the updates about conan-center-index. The community can still add the support for Conan package manager in this project if the maintenance effort for it is reasonable and if it will yield benefits for our userbase. If anyone is looking into this, please feel free to open a PR. Thanks!