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.
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.
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.
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.
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.
Fix precision warnings when FloatDefault is 64 bit
When VTKm_USE_DOUBLE_PRECISION is on (not the default), then
vtkm::FloatDefault is set to 64 bit values. There was some code that was
coded for 32 bit and never checked for 64 bit (on all compilers).
See merge request !526
1881d375 Explicitly error out if vtk-m is used with a non c++11 compiler.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kenneth Moreland <kmorel@sandia.gov>
Merge-request: !532
When VTKm_USE_DOUBLE_PRECISION is on (not the default), then
vtkm::FloatDefault is set to 64 bit values. There was some code that was
coded for 32 bit and never checked for 64 bit (on all compilers).
The UnitTestMapperGLFW test was coded to run in an interactive mode,
which was problematic when simply running the test. If no one was there
to exit the interactive window, the test would time out. This change
adds a "batch" mode that is on when run by ctest. The batch mode runs
through all configurations and exits.
Fix configuration of dependent rendering libraries
The VTKmConfigureComponents.cmake file has lots of careful configuration
of many of VTK-m components and dependent libraries (like OpenGL,
OSMesa, etc.) that takes care of several corner cases. The configuration
is consolidated here so that it can be consistent across the many
directories in VTK-m as well as other projects that use VTK-m.
Recent changes to the configuration in rendering circumvented these and
directly tried to configure dependent rendering libraries. This is wrong
(and more importantly broke my OSX build).
See merge request !519
The VTKmConfigureComponents.cmake file has lots of careful configuration
of many of VTK-m components and dependent libraries (like OpenGL,
OSMesa, etc.) that takes care of several corner cases. The configuration
is consolidated here so that it can be consistent across the many
directories in VTK-m as well as other projects that use VTK-m.
Recent changes to the configuration in rendering circumvented these and
directly tried to configure dependent rendering libraries. This is wrong
(and more importantly broke my OSX build).
Previously there was a bug where BufferTypePicker was not implemented
correctly when LONG was 32 bits (even though 64 bit integers were
available).
This changes fixes the problem and also makes the implementation more
general by using the TypeTraits already available.
The testing subdirectories were including the tests from the parent
directory. I believe this was a copy-paste error from the tests
originally all being in one file (where the unit_tests variable had all
tests appended) and then moved to subdirectories where they should not
be appended.
14ad996d Update vtk-m to use CopySubRange where applicable.
51e50d29 Add DeviceAdapter::CopySubRange to all device adapters.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !516
