add CMake presets

[SimeonEhrig]

add CMake presets to make it easier to compile alpaka for different backends

TODO

• add missing backends
• write documentation

Usage

cd <alpaka_root>
cmake --preset gpu-cuda-nvcc-gcc
cmake --build --preset gpu-cuda-nvcc-gcc
ctest --preset gpu-cuda-nvcc-gcc 

Testing

Because of more urgent other tasks I will add tests later during working on PR #919 and #1019. If the CMake presets get broken, nothing else will be affected.

[SimeonEhrig]

@bernhardmgruber @psychocoderHPC Can you please have a look on the name scheme of the profiles and also the enabled arguments.

[bernhardmgruber]

I think that except for the gpu-sycl-intel preset, where the cmake options are harder to figure out, this CMake presets file would not help me much :S

In LLAMA, I use this for example:

    {
      "name": "default",
      "toolchainFile": "~/dev/vcpkg/scripts/buildsystems/vcpkg.cmake",
      "cacheVariables": {
        "BUILD_TESTING": "ON",
        "LLAMA_BUILD_EXAMPLES": "ON",
        "alpaka_ACC_CPU_B_SEQ_T_SEQ_ENABLE": "ON",
        "Boost_NO_WARN_NEW_VERSIONS": "ON"
      }
    }

Because specifying the toolchain file annoying, I don't have tests and examples enabled by default, but this is what I do locally almost 100%. I suppress Boost warnings in CMake and I want to usually have the alpaka serial accelerator, so all examples compile.

For alpaka, I would rather use a similar config, e.g.:

    {
      "name": "minimal",
      "cacheVariables": {
        "BUILD_TESTING": "ON",
        "alpaka_BUILD_EXAMPLES": "ON",
        "alpaka_ACC_CPU_B_SEQ_T_SEQ_ENABLE": "ON",
        "Boost_NO_WARN_NEW_VERSIONS": "ON"
      }
    }

Or one to have all CPU backends:

    {
      "name": "all_cpu",
      "cacheVariables": {
        "BUILD_TESTING": "ON",
        "alpaka_BUILD_EXAMPLES": "ON",
        TODO: enable all CPU backends
        "alpaka_ACC_CPU_B_SEQ_T_SEQ_ENABLE": "ON",
        "Boost_NO_WARN_NEW_VERSIONS": "ON"
      }
    }

I think the CMake presets should not provide yet another configuration mechanism to enable/disable backends, ccmake works good for this, but rather support common work flows.

[SimeonEhrig]

The basic idea of the presets are the following:

• use it directly for the alpaka project -> for own projects using alpaka, you should write your own presets.
• show how to enable the different backends. In special the sycl backend is pretty hard to enable

I would also not enable all CPU backends at the same time. This requires that you install OpenMP and Intel TBB on your system on the same time.

And I avoid to use ccmake where I can because it introduce a new source of errors. It causes undocumented changes in the cmake configuration. Better would be to create a new user specific preset. With this preset you know what you did every time. Also you can simply delete the build and configure it again.

[bernhardmgruber]

The basic idea of the presets are the following:

• use it directly for the alpaka project -> for own projects using alpaka, you should write your own presets.

Right, so it's intended for developers and not downstream users.

• show how to enable the different backends. In special the sycl backend is pretty hard to enable

We don't need that, because this is what documentation is for.

I would also not enable all CPU backends at the same time. This requires that you install OpenMP and Intel TBB on your system on the same time.

Which I have and whenever I want to test all backends, I would want to have a preset for this :)

And I avoid to use ccmake where I can because it introduce a new source of errors. It causes undocumented changes in the cmake configuration. Better would be to create a new user specific preset.

I completely disagree, it's the bread and butter of configurating. It's very approachable and nicely shows what kind of options a project has.

With this preset you know what you did every time. Also you can simply delete the build and configure it again.

That's a fair point and that's why I configure with a fixed command line when doing reproducible benchmarks. But for normal coding, ccmake and change whatever I want.

[bernhardmgruber]

Anyhow, I let @psychocoderHPC take over this review.

[SimeonEhrig]

We don't need that, because this is what documentation is for.

I prefer an interactive documentation compare to text. It's true, I can compile all information from the README. But why I should do it, if the preset is already doing it for me?

Which I have and whenever I want to test all backends, I would want to have a preset for this :)

Fine, I will add one. I will not hurt.

I completely disagree, it's the bread and butter of configurating. It's very approachable and nicely shows what kind of options a project has.

That's a fair point and that's why I configure with a fixed command line when doing reproducible benchmarks. But for normal coding, ccmake and change whatever I want.

We work completely different. I only use directly cmake if I want to build a project. If I want to develop a project, vsc is doing all the stuff. I don't want to think about cmake configuration. The computer should do this. I would get mad if I need to care about. I use a least 4 different systems and switches quickly ;-)

[SimeonEhrig]

@bernhardmgruber After our discussion, I would do the following things:

• remove the types to make the json much easier
• unify each cpu backend version of gcc and clang to a single cpu backend version without explicit CXX compiler
• add a cpu backend configuration which enables: serial, both OpenMP 2, threads? [1], Intel TBB

[1] I'm not sure if we should enabled std::threads, because the execution time of the examples and tests are horrible

I would keep setting the CXX compiler for Intel Sycl and AMD HIP because this is a big source of errors to forget it.

My idea of the presets is, that you have a preset for each backend that you have an easy start point to build the examples and tests for the backend. And you can use the presets to inherent from it with your CMakeUserPresets.json or configure an build and modify it afterwards with ccmake.

Personally, I will not use the CMakePresets.json directly. I want to inherent from it via CMakeUserPresets.json, set ninja as build generator and create a debug and release version of each backend, which I can switch easily in vsc.

[bernhardmgruber]

@SimeonEhrig do what works best for you! And I like your suggestions. I also did not know about CMakeUserPresets.json.

[bernhardmgruber]

@psychocoderHPC please also share your opinion on how you would want to use presets, or not :)

@SimeonEhrig: btw, great work on the documentation!

[SimeonEhrig]

@bernhardmgruber René wrote in the internal chat, that he cannot give feedback and is fine with your review.

[bernhardmgruber]

@bernhardmgruber René wrote in the internal chat, that he cannot give feedback and is fine with your review.

Great! However, I do not have the permissions to merge a PR with failing tests or with @psychocoderHPC's review pending. You have to ask @psychocoderHPC to merge it.