The VTK-m testing infrastructure isn't public facing so it doesn't
need to be installed or clutter the main VTKmWrappers file.
At the same time I have refactored the code to make it clearer
to understand, and remove unused options.
Previously an installed version of VTK-m wasn't relocatable as
it had system MPI paths. Additionally the installed vtkm_diy target
would depend on MPI but not `find_package(MPI)`
We now have a couple of the examples also being built against
the installed version of VTK-m as a test. This allow us to verify
that VTK-m installs and can be found properly.
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.
Found via `codespell` and `grep`
more typos
includes source typo change and a typo that needs further review
follow-up typos
Follow-up typos
Revert a commit
The goal is to provide a way to disable VTK-m warning flags when used as a
thirdparty library.
VTK-m's stricter warning flags were cauing several new warnings in VTK.
The check to determine the version of VTK-m from git was duplicated in
CMakeLists.txt. Although pointless, it generally was not a big deal
(only an extra check when running CMake). Except for some reason with
the latest changes to the CMake build the second time find_package(Git)
was called on my system the GIT_EXECUTABLE variable got cleared out and
that caused the configure to fail. I have no idea why this happens (and
running CMake again seems to fix the problem), but simply removing the
extraneous find seems fix the problem.
VTK doesn't hide symbols for static builds, which results in linker
errors for VTK targets that link with VTK-m. This option allows VTK-m
to match VTK's behavior.
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.
