René Widera

> We discussed today in VC and seems that this issue and #1613 could be solved changing some Makefile logic for compiling alpaka applications. @psychocoderHPC Currently alpaka's accelerators are enabled...

> > I expect that the list of available devices should not change during a program's execution, so would it make sense to discover this information once and store it...

@SimeonEhrig Could you please test this feature when you are back?

I am a little bit unhappy that this PR is mixing features, refactorings, and adding new test combinations. Could you split e.g CUDA keyring refactorings, job renamings and new jobs...

I suggest to create one container for each architecture e.g. BaseNvidia, BaseX86, BaseOpenPower and BaseArm. All container should have compiled the dependencies (e.g. Boost, CMake) in all needed versions (best...

> Do you mean, the CI Job should look something like this: > > ```shell > $> docker pull x86container > $> docker run x86container > $container> spack load [email protected]...

As I know our CI can do it or we use our dev system in the office to build the container.

> I am not sure if you already need spack since the goal is to keep Alpaka very-low on dependencies, besides vendor libs. Spack will be only used to maintain...

Splitting by compiler makes IMO sense. I can test the container on our dev system. Thats the only system with docker where I have access. Am 31. März 2020 17:25:16...

> I would really like to use the pre-installed docker images in the github actions. This would make the CI much faster. @SimeonEhrig already [prepared docker container](https://github.com/alpaka-group/alpaka/issues/967#issuecomment-606696681) for alpaka. We...