Install test

[yasahi-hpc]

Resolves #43
Resolves #66

This PR aims at recovering CI for using KokkosFFT as subdirectory or library.

1. Build app using KokkosFFT as a subdirectory in CMake project
2. Build app using Kokkos and KokkosFFT as libraries in CMake project
3. Add these tests in CI
4. fix CMake issues when using KokkosFFT as a subdirectory
5. docs would be updated based on the changes

[pzehner]

Based on our previous discussion, testing the installation of KokkosFFT should be done in a different job:

install:
  # same `needs` and `if` as the `build` job.
  # the `strategy` may be similar, without testing host-device configuration (i.e. drop
  # the `target` matrix), and maybe without some configurations (i.e. no threads and
  # serial?)

The content of the files as_subdirectory.sh and as_library.sh should appear within the test as maybe two separate steps. Having script files lying around in the source tree that are only used for CI is not a good thing. Instead of re-downloading Kokkos, I think we can re-use the one in /tpls by copying it (which makes it consistent with the build tests).

I don't like the idea to duplicate the install test file, but I think it's better to keep two separate directories for the library and the subdirectory approaches, as they require different CMakeLists.txt files. Maybe just reduce the test file to its simplest expression.

[yasahi-hpc]

@pzehner Thanks for the comments

Based on our previous discussion, testing the installation of KokkosFFT should be done in a different job:

install:
  # same `needs` and `if` as the `build` job.
  # the `strategy` may be similar, without testing host-device configuration (i.e. drop
  # the `target` matrix), and maybe without some configurations (i.e. no threads and
  # serial?)

The content of the files as_subdirectory.sh and as_library.sh should appear within the test as maybe two separate steps. Having script files lying around in the source tree that are only used for CI is not a good thing. Instead of re-downloading Kokkos, I think we can re-use the one in /tpls by copying it (which makes it consistent with the build tests).

That makes sense. I will update accordingly.

I don't like the idea to duplicate the install test file, but I think it's better to keep two separate directories for the library and the subdirectory approaches, as they require different CMakeLists.txt files. Maybe just reduce the test file to its simplest expression.

Do you mean we should modify each CMakeLists.txt to refer to a single source file, say,

add_executable(hello-kokkos-fft ../src/hello.cpp)

[pzehner]

Do you mean we should modify each CMakeLists.txt to refer to a single source file, say,

add_executable(hello-kokkos-fft ../src/hello.cpp)

We would end up with the following layout:

install_test
    +-- main.cpp
    +-- as_library
    |   +-- CMakeLists.txt
    +-- as_subdirectory
        +-- CMakeLists.txt

Which is not very common. It's up to you I guess.

[yasahi-hpc]

Do you mean we should modify each CMakeLists.txt to refer to a single source file, say,

add_executable(hello-kokkos-fft ../src/hello.cpp)

We would end up with the following layout:

install_test
    +-- main.cpp
    +-- as_library
    |   +-- CMakeLists.txt
    +-- as_subdirectory
        +-- CMakeLists.txt

Which is not very common. It's up to you I guess.

I may prefer self-contained examples like

 install_test
    +-- as_library
    |   +-- CMakeLists.txt     
    |   +-- hello.cpp
    +-- as_subdirectory
        +-- CMakeLists.txt
        +-- hello_again.cpp

Using slightly different examples. Is it fine with you?