CMake Standalone Support

[crtrott]

There are 2 use cases for building Kokkos:

1. Build against an already installed library.
2. Build Kokkos as part of the application build.

The first is addressed by @pkestene in #633.

The second is being addressed by @gmackey and has the following dependent tickets:
#243
#629
#654
#667
#668
#688

[gmackey]

The first use case is already in develop.

[gmackey]

The cmake branch in my fork also includes improvements to the Makefile build and to the snapshot script The tickets related to those are
#697
#673
#701
#702
#703
#704
#705
#706
#717

[dholladay00]

If I want to use a branch with this feature, is build-cleanup or task-dag the better choice?

[bjoo]

Question: Does the standalone CMake support a 'make install' target? E.g. at the Kokkos Training, I dropped kokkos/ into a subdirectory of my mini-app, which is a library + unit tests. When I type make, Kokkos is built and is linked with my library. However, when I type 'make install' only my library components are installed but Kokkos is not.

Would there be an issue if someone wanted to link against my library?

[crtrott]

Looks like that install thing is missing. And yes for a library you would want to install kokkos along side your library.

[dholladay00]

In my case, I believe applications that link against my library must also link against kokkos.

I'm guessing there's a way for cmake to include kokkos in the make install step though.

[crtrott]

Actually you might just need to add the kokkos library to your list of things that need installing (in your libraries install command).

[bjoo]

I tried this and tried adding

install(TARGETS kokkos DESTINATION kokkos)

in various places ( My toplevel CMakeLists.txt, or the one in my lib/ Directory)
I also tried adding it into the kokkos.cmake file in the kokkos/cmake/ dir.
None of these worked, tho I am a relative newcomer to CMake, so it may be my fault.

One thing I could probably do is install the whole kokkos subdirectory. But then clients of my
library would need to rebuild it, so that seems the wrong approach.

I can try to look at the CMakeLists.txt files in Kokkos, but I don't want to mess anything up for TriBits builds.

[dholladay00]

From what I can tell, Kokkos is meant to be built with the rest of the application. If you look at how their examples and tutorial Makefiles are structured, that is what they do. The main reason I can think of is combinatorics, but they could have other motivations. The Kokkos developers could answer that better than I.

It can be prebuilt and linked against, but I don't think it is recommended. Also, going that route, you can use their makefile generator script and build kokkos without needing to use their cmake at all. You could also look into the recently added Kokkos Spack module.

Another potential option is, if machines already have Trilinos, to link against the Trilinos-Kokkos libraries (that process is slightly different from standalone Kokkos though). Also, in that case, you're stuck with whatever configuration the Trilinos-Kokkos was built with.

As someone who has used the above methods (Trilinos didn't work for me b/c that version did not have the features I needed), my experiences tell me to recommend building with the application.

[bjoo]

Hi Daniel, I am trying to use Kokkos to provide infrastructure to a library I am building. My library currently builds with CMake. So to build my library, I build Kokkos with it, just as you suggest and how we set it up last week at the Tutorial. However, when I install my library, the Kokkos I just built needs to be installed also (with the configuration options baked in), so that applications linking against my library don’t end up with unresolved symbols etc The other approach (which I would otherwise use) is to install Kokkos (separate installs for all the configurations I am planning to use) and build my library against the appropriate one. In this case what would be useful would be a FindKokkos.cmake style file, which would just export to my build the options Kokkos needs. Alternatively a pkg-config script can be used to do this, which could be used both from CMake builds or Autoconf/Autotools builds. However, since the intention is that the Kokkos used by my library is not visible to the application directly (only indirectly through my library's interface), it would be nice it if could be built with the library and then the two could be installed together. Best, Balint

…

On May 9, 2017, at 11:31 AM, Daniel Holladay ***@***.***> wrote: From what I can tell, Kokkos is meant to be built with the rest of the application. If you look at how their examples and tutorial Makefiles are structured, that is what they do. The main reason I can think of is combinatorics, but they could have other motivations. The Kokkos developers could answer that better than I. It can be prebuilt and linked against, but I don't think it is recommended. Also, going that route, you can use their makefile generator script and build kokkos without needing to use their cmake at all. You could also look into the recently added Kokkos Spack module. Another potential option is, if machines already have Trilinos, to link against the Trilinos-Kokkos libraries (that process is slightly different from standalone Kokkos though). Also, in that case, you're stuck with whatever configuration the Trilinos-Kokkos was built with. As someone who has used the above methods (Trilinos didn't work for me b/c that version did not have the features I needed), my experiences tell me to recommend building with the application. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

-------------------------------------------------------------------------------------- Dr Balint Joo High Performance Computational Scientist Jefferson Lab 12000 Jefferson Ave, Suite 3, MS 12B2, Room F217, Newport News, VA 23606, USA Tel: +1-757-269-5339, Fax: +1-757-269-5427 email: bjoo@jlab.org -------------------------------------------------------------------------------------

[dholladay00]

I see … There is probably a cmake-y way to add Kokkos as one of the install targets, but I'm not familiar with that.

[pfultz2]

Actually, you can export the targets, so they can be used downstream. This article here explains a simple way of doing that(however a slightly different approach is needed if kokkos uses imported targets):

  add_library(
    kokkoscore
    ${KOKKOS_CORE_SRCS}
  )

  # Adjust the include directories so the installed target doesn't include
  # files from the build and source directories
  target_include_directories(
    kokkoscore
    PUBLIC $<BUILD_INTERFACE:${Kokkos_SOURCE_DIR}/core/src>
    PUBLIC $<BUILD_INTERFACE:${KOKKOS_INCLUDE_DIRS}>
    PUBLIC $<BUILD_INTERFACE:${Kokkos_BINARY_DIR}>     # To include generated KokkosCore_config.h.
    SYSTEM PUBLIC $<INSTALL_INTERFACE:$<INSTALL_PREFIX>/include>
  )

  # ... the rest of the targets

  # Install the kokkos library targets
  install(TARGETS kokkoscore kokkos kokkoscontainers kokkosalgorithms EXPORT kokkos-config
    ARCHIVE  DESTINATION ${CMAKE_INSTALL_LIBDIR}
    LIBRARY  DESTINATION ${CMAKE_INSTALL_LIBDIR}
    RUNTIME  DESTINATION ${CMAKE_INSTALL_BINDIR})

  # Install the kokkos exported targets
  install(EXPORT kokkos-config DESTINATION share/kokkos/cmake)

  # Export the targets
  export(TARGETS kokkoscore kokkos kokkoscontainers kokkosalgorithms FILE kokkos-config.cmake)

Then the user can do:

find_package(kokkos)
add_library(foo foo.cpp)
target_link_libraries(foo kokkoscore)

[ibaned]

I wrote a set of CMake helper functions to automate some of the trickier parts of this:

https://github.com/ibaned/cmake_bob

[bjoo]

Thanks Paul, Dan I will work through these.