UnitTestMapperEGL.cxx: MapperGL is no longer a templated class.
UnitTestMapperGLFW.cxx: strmp needs cstring
rendering/CMakeLists.txt: need to append egl_sources to sources.
Add glut rendering unittest.
Make the GLFW package variables advanced, and add it to the configure components.
Modify the other examples that use GLUT to use the configure components command.
See merge request !546
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.
Remove boost::shared_ptr from rendering library
The remove boost::shared_ptr and the rendering library branches where
developed simultaneously, and thus some of the rendering library
implementation was using boost::shared_ptr like the old code. Bring up
to date with the rest of VTK-m by using std::shared_ptr instead.
See merge request !549
The remove boost::shared_ptr and the rendering library branches where
developed simultaneously, and thus some of the rendering library
implementation was using boost::shared_ptr like the old code. Bring up
to date with the rest of VTK-m by using std::shared_ptr instead.
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
Make the GLFW package variables advanced, and add it to the configure components.
Modify the other examples that use GLUT to use the configure components command.
The clang compiler was running into linker errors constructors of
classes with virtual methods that were inline and destructors that were
not declared at all. In this case, the compiler was not creating
everything needed by a virtual table and the link died.
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.
One of the dashboards is complaining about the destructor implementation
not being used in a particular test build. I suspect it is because the
export macro has an inline, so I am trying removing 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.
I noticed that Visual Studio was taking an insane amount of time to
compile BitmapFontFactory.cxx (~20 minutes). Following some suggestions
on stackoverflow (http://stackoverflow.com/questions/7893850/long-
compile-times-in-visual-c-2010-with-large-static-arrays) I changed the
arrays to be static const (something that is more viable when compiling
a library instead of header-only). The compile after this changes seems
basically immediate now.
Also made the TextAnnotation classes conform better to VTK-m coding
style. Specifically, changed the order of words in subclass names (e.g.
TextAnnotationBillboard instead of BillboardTextAnnotation) and broke
out each subclass into its own header/source files.
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.
When things in the rendering library need to execute things in parallel
(outside of another rendering library like OpenGL) it should run it on
available parallel devices. This means using TryExecute to attempt on
whatever devices may be available. It also means that some of the
sources must be compiled with CUDA's nvcc. To enable this, made a code
wrapping mechanism to compile within a .cu file.
This is using the C++11 override keyword to make the compiler check to
ensure that we are correctly overriding virtual methods when we mean to.
Currently this will not compile without C++11. However, we are planning
on moving to C++11 very soon, and we can fix the macro if we don't.
