This is a work around while we wait on requiring CMake 3.15 for all
cuda builds. At that point we can replace this with setting
`requires_static_builds` as part of the EXPORT_PROPERTIES of the
vtkm_cuda target.
This has been tested with the ascent proxy
This is a work around while we wait on requiring CMake 3.15 for all
cuda builds. At that point we can replace this with setting
`cuda_architecture_flags` as part of the EXPORT_PROPERTIES of the
vtkm_cuda target.
This has been tested with the ascent proxy
In certain circumstances (currently, when logging is enabled), VTK-m
libraries depend on the threading library. However, when the VTK-m
package was included from an external project, it did not automatically
find the threads package. This change makes the Threads library loaded
when the VTK-m package is found.
CMake 3.12 introduces a ...<max> syntax in the version given to
cmake_minimum_required to automatically set policies to NEW up
to that version. Use it to avoid listing policies explicitly.
Previously vtkm_find_gl was only usable when rendering was enabled.
This is problematic as examples would use vtkm_find_gl even if
they didn't use vtkm rendering library.
Sandia National Laboratories recently changed management from the
Sandia Corporation to the National Technology & Engineering Solutions
of Sandia, LLC (NTESS). The copyright statements need to be updated
accordingly.
This makes the name more consistent with the names of the other VTK-m
CMake options.
Also changed the default to be ON. I do not see a big downside to
compiling the rendering library most of the time.
Rendering library
Pull the majority of the implementation of the rendering
package into a library for better compile performance.
See merge request !527
A big part of the VTK-m find_package configuration is a set of
components that load different parts of VTK-m's configuration. If you
load none of the components, you do not actually get enough to compile
any part of VTK-m, which is confusing. To get around this, always load
the "Base" component.
There were a couple of places where the configure scripts did not add
either includes to VTKm_INCLUDE_DIRS or libraries to VTKm_LIBRARIES.
The biggest offender was when the examples used find_package to load the
VTK-m configuration it needed. find_package cleared out the includes and
libraries, but it did not clear out the VTKm_<COMPONENT>_FOUND
variables. Normally, these variables would not be set before
find_package is called, but in this case the examples were called after
some partial configuration. I got around this issue by clearing out all
the *_FOUND variables in VTKmConfig.cmake.
To detect what CUDA hardware is native, a simple CUDA program is
compiled. However, CMake was not necessarily pointing to the correct
source file, so the compile was failing.
This change makes sure that VTKm_CMAKE_MODULE_PATH is properly set and
uses that variable to find the source file.