Several revisions ago, the ability to use virtual methods in the
execution environment was deprecated. Completely remove this
functionality for the VTK-m 2.0 release.
As we remove more and more virtual methods from VTK-m, I expect several
users will be interested in completely removing them from the build for
several reasons.
1. They may be compiling for hardware that does not support virtual
methods.
2. They may need to compile for CUDA but need shared libraries.
3. It should go a bit faster.
To enable this, a CMake option named `VTKm_NO_DEPRECATED_VIRTUAL` is
added. It defaults to `OFF`. But when it is `ON`, none of the code that
both uses virtuals and is deprecated will be built.
Currently, only `ArrayHandleVirtual` is deprecated, so the rest of the
virtual classes will still be built. As we move forward, more will be
removed until all virtual method functionality is removed.
`assert` is supported on recent CUDA cards, but compiling it appears to be
very slow. By default, the `VTKM_ASSERT` macro has been disabled whenever
compiling for a CUDA device (i.e. when `__CUDA_ARCH__` is defined).
Asserts for CUDA devices can be turned back on by turning the
`VTKm_NO_ASSERT_CUDA` CMake variable off. Turning this CMake variable off
will enable assertions in CUDA kernels unless there is another reason
turning off all asserts (such as a release build).
Fixes#447
This uses a more robust set of checks to determine if std::aligned_union
and std::is_trivially_copyable exist given the libstdc++ version value
Previously, Configure.h.in used a pragma to disable warning 4996 is all
VTK-m code and anything that used it. The reason for this was that the
warning was given for any use of std algorithms such as fill_n that the
Visual Studio team deemed unsafe. Although we could fix it in our code,
it was impossible to work around warnings in other headers as the actual
warning comes from a system header file (xutility) that we have very
little control over. At the time we disabled this warning, we were
getting the warning from a bost header file, and the warning was never
to be fixed (https://svn.boost.org/trac/boost/ticket/11426).
Unfortunately, disabling warning 4996 also disables all warnings about
deprecated items. We want to support warnings for things deprecated in
VTK-m itself, so turning off this warning means we cannot correctly
support VTK-m deprecation.
Fortunately, a lot has changed since then. We no longer boost at all, so
the issue there is no longer our problem. We can thus re-enable the
warning (by removing the pragma). We've managed to avoid using these
"unsafe" functions anyway, so we should be able to cleanly build with
this warning on.
The `VTKM_DEPRECATED` macro allows us to remove (and usually replace)
features from VTK-m in minor releases while still following the conventions
of semantic versioning. The idea is that when we want to remove or replace
a feature, we first mark the old feature as deprecated. The old feature
will continue to work, but compilers that support it will start to issue a
warning that the use is deprecated and should stop being used. The
deprecated features should remain viable until at least the next major
version. At the next major version, deprecated features from the previous
version may be removed.
This is only set while compiling device code, and is useful
for code that needs different implementations on devices (e.g.
they call CUDA device intrinsics, etc).
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.
VTKM_PASS_COMMAS(...) will pass it's arguments verbatim into another
macro, even if they contain commas. This is helpful when using templated
classes, e.g.
#define SOME_MACRO(arg) ...
SOME_MACRO(vtkm::cont::ArrayHandle<float, StorageTag>)
won't compile, because the comma in the template parameters is assumed
to be separating macro arguments. Adding extra parenthesis,
SOME_MACRO((vtkm::cont::ArrayHandle<float, StorageTag>))
helps in some cases, but not others (e.g. the macro declares a variable).
SOME_MACRO(VTKM_PASS_COMMAS(vtkm::cont::ArrayHandle<float, StorageTag>))
will always* work.
windows.h was only being included for MSVC, while in UnitTestTimer.cxx, the
Windows function Sleep was being called after check for _WIN32. This was
causing compilation failure in MINGW.
Fixes#122
It is common practice to swallow a semicolon in a macro using a do/
while(false) loop that only executes once. However, the Visual Studio
2013 compiler was stupidly warning about having a constant expression
for the loop. Get around the problem by creating our own swallow
semicolon macros that disable this warning as necessary.
In VTK-m libraries, we are typically exporting (with declspec) classes rather
than the independent methods within the class. When you are exporting to a
dll in MSVC and the class contains a field that is not similarly exported,
then you get a warning. This is generally not an issue for our use since we
are really only using classes from the standard library and distributed with
VTK-m itself. The only sane way to fix the issue is to just disable the
warning.
a6609311 Silence auto_ptr deprecation warnings with older boosts ( < 1.61 )
6d38f44d Update ListTag and DispatcherBase to leverage C++11 features.
ea0d84a8 Remove VTK-m Variadic defines and replace them with a single CXX11 define
77121d18 Add support to VTK-m to build with C++11
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !475
Add pragmas to disable warnings 4244 and 4800 on Visual Studio when
compiling third party libraries. This gets around some warnings inside
the thrust library.
