By default visual studio limits the number of sections in an object file
to 2^16 which isn't enough when creating some of our tests. So we enable
/bigobj which increases that number to 2^32.
Porting the dax device adapter over to vtkm. Unlike the dax version, doesn't
use the thrust::device_vector, but instead uses thrust::system calls so that
we can support multiple thrust based backends.
Also this has Texture Memory support for input array handles. Some more work
will need to be done to ArrayHandle so that everything works when using an
ArrayHandle inplace with texture memory bindings.
The previous behavior of the pyexpander check (in
VTKmCheckPyexpander.cmake) was to generate the file in the binary
directory and then remove it from there iff the check failed. This
caused two problems. The first is that if the check failed then the file
was deleted and there was no file to copy to the source as the
instructions suggested. The second is that if the check succeeded the
build would then use the files in the build directory rather than the
source directory, and if the programmer accidently modified the binary
files (because, for example, if a build error occured there), the
configure system would not catch that.
This change in behavior was that if the check failed, the file is
renamed to have a .save extension so that the file remains and can be
easily copied back to the source directory if that is appropriate. If
the check succeeds, the generated file is removed and a file with the
extension .check is touched. That .check file is used as a make target
to signal that the test has been performed.
The CMake template for the source file that contains the main function for
tests uses functions that MSVC considers unsafe. We want to check for these
conditions but have no control over the CMake-generated test code (which
looks right anyway). This disables the warning specifically for those
source files but nothing else.
Although we cannot expect every developer to have pyexpander, for those
that do the build will automatically run it and check the expanded file
in the source code. If they match, a descriptive error is given.
We don't automatically update the file because subtle problems might
occur. It is better to alert a developer to fix the problem properly.
