Class that need to be passed across dynamic library boundaries such as
DynamicArrayHandle need to be properly export. One of 'tricks' of this
is that templated classes such as PolymorphicArrayHandleContainer need
the Type and Storage types to have public visibility.
This makes sure that all vtkm storage tags have public visibility so
in the future we can transfer dynamic array handles across libraries.
During a round of resolving compile issues on the dashboard, the test
builds were disabled, but never re-enabled. This change re-enables the
test builds.
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.
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.
The previous attempt at using caching to prevent duplicate commands, failed
when you tried to build VTK-m itself and had examples turned on. Now we
just don't add the std=c++11 option if it already exists.
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.
When you called find_package multiple times with VTK-m components such as CUDA
would continuously append to variables, causing a variable to have the same
parameter listed multiple times.
Properly cache the results of CUDA native detection.
I found some issues when using VTK-m from inside VTK. The issues where
that on reconfigures the device architectures flags where dropped by the
caching mechanism.
See merge request !555
I found some issues when using VTK-m from inside VTK. The issues where
that on reconfigures the device architectures flags where dropped by the
caching mechanism.
123bc8b6 Add a configuration error if OSMesa was not found
0a61085d Do not load OpenGL libraries if OSMesa already loaded
640e92c7 Add VTKm_ENABLE_OSMESA option
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !548
It is standard now in CMake to make the CMake configuration variables
(like those specifying paths to files for a library) are marked as
advanced. Otherwise, the CMake configuration gets overwhelmed by lots of
parameters that are either found automatically or only need to be set
once.
The test builds are created by making some library targets for libraries
with nothing useful. (The intention is to test a build of the code, not
use the built code.) To prevent linking issues, each test build defines
a function named Test_Build_For_<headername>.
However, when BUILD_SHARED_LIBS was on for windows, it never actually
exported anything because dlls need a __declspec(dllexport) on it. Thus,
nothing was exported from the library, and that could cause issues with
the build system (e.g. https://public.kitware.com/Bug/view.php?
id=15885). To get around the issue, always compile the test build
libraries as static.
Rendering library
Pull the majority of the implementation of the rendering
package into a library for better compile performance.
See merge request !527
Always load "Base" component in find_package
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.
See merge request !541
The target_compile_options expects the arguments to be in a CMake list.
However, the variables used to hold CMake lists are space separated to
be just put in a command line. Thus, call separate_arguments on the
string before using it.
We moved to using the more modern signature of target_link_libraries,
but on some platforms this causes a configuration error. The issue is
that cuda_add_library internally uses target_link_libraries with the old
signature, and CMake does not allow us to use both signatures on the
same target.
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.
A recent change to the rendering library has a source code in the
internal subdirectory references from the rendering directory. This
makes sense as we want all the components (whether externally visible or
not) to be in the same library. However this broke the SourceInBuild
tests as the source code was technically not referenced from the
CMakeLists.txt in the same directory.
Anticipating that this could be a common occurance, I modified the test
to also check the CMakeLists.txt in the parent directory.
