Files like VTKmConfig.cmake are now under:
prefix/lib/cmake/vtkm-1.0/, rather than
prefix/lib
to allow multiple vtkm versions to share an installation prefix.
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.
When used as a submodule, redefining LIBRARY_OUTPUT_PATH and
EXECUTABLE_OUTPUT_PATH fails since the CMake default variables from the
containing project already exist.
CMake has several default build types, but if nothing is specified when
configuring your project it defaults to an empty string and no optimization
flags are used.
It will now default to using a debug build if the source directory is a git
clone, or a release build if not. Additionally when using ccmake or cmake-gui
this will provide a nice list of possible options for CMAKE_BUILD_TYPE.
Change the OpenGL configuration to require GLEW as most of the OpenGL
code actually requires GLEW (or will as soon as the VBO branch gets
merged in).
Also removed some stray find_package commands and rearranged the
configuration to use the vtkm_configure_component_* commands instead.
The vtkm/CMake directory has several Find*.cmake configuration files
that were used both by the base VTK-m configuration as well as
configuration of projects that use VTK-m. However, several of these
files (particularly the newer ones) were not installed. This change
fixes that.
The VTKmDetectCUDAVersion.cxx source file used during configuration to
detect the native version of CUDA hardware was renamed to
VTKmDetectCUDAVersion.cu. However, the old filename was still trying to
be installed, which caused the install target to fail.
Recently VTK-m was changed to require C++11. The internal builds set
properties to require C++11, but these never make it to the
configuration for projects that use the VTK-m package (i.e. not declared
in VTKmConfig.cmake).
This change adds a new CMake target, vtkm, which is an interface. It
does not point to an actual library, but it allows code that links it in
to have the appropriate compile flags.
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.
Currently, the only library created is for the rendering package. If
VTKm_BUILD_RENDERING is off, then no libraries are created. If no
libraries are created, then there is nothing that declares a VTKmTargets
export. If there is nothing that creates a VTKmTargets export, the
export command fails.
Aaarg!!!! I can't even find a way to query whether an export is valid
(in the same way you can query whether a target exists). I added a
global variable that recorded whether vtkm_library added a library
(where things are added to the VTKmTargets export). The export command
is called if any libraries were created, a stub is created and installed
otherwise.
I have noticed at least on my windows machine that source code that uses
the rendering package is taking a long time to compile. The rendering
library does not rely much on templates and more on virtual methods.
Thus, it is a good candidate for moving to a library so that it need be
compiled only once.
This sets up the configure scripts to create the library. There is also
a simple port of one class to the library. More will follow.
CMake policy CMP0058, introduced in CMake 3.3, requires that all
intermediate files created during the build process will be declared as
an output or byproduct of a target. See "cmake --help-policy CMP0058"
for details.
Per this policy, CMake was giving a warning about some files generated
during configuration (e.g. with configure_file) because they were files
in the build directory with no apparent target command. This is not an
issue since the configure will ensure that the file is always there
before the build starts. Thus, we declare that we will adhere to the new
policy to avoid the warning.
The examples configuration now behave like external projects and use
find_package to configure themselves. As such that file should be built
before we try to configure the examples.
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.
When finding the VTKm package, it is important to load components that
support the devices you want to use. However, there is no indication of
what does and does not get loaded. In some circumstances, it simply says
that VTKm_FOUND is not true but not why. Add some status messages of
whether each component gets loaded or not.
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.
Have VTK-m eat its own dog food when it comes to its configuration. Load
the same configuration for building VTK-m as would be loaded (more or
less) when using find_package(VTKm) in an external project.
This includes adding lots more components to the packages so that all the
setup (e.g. OpenGL, TBB, etc.) can be set up correctly. It is also a
significant change to how these components are declared. The component
configuration is simplified a bit and unified in a single file.
