The test for particle advection filters was one large test that tested 3
versions --- advection, streamlines, and pathlines --- with each tested
for a variety of conditions including asynchronous communication, number
of blocks, ghost cells, etc. This was causing the test to take a while
and sometimes time out. (It would also sometimes seg fault, which I hope
is related.) To attempt to fix this problem, break up this test into
pieces so that each piece takes a shorter amount of time.
Because these tests share most of their implementation (which is why
they were grouped together in the first place) the common code is placed
in a source file of shared implementation. To support this I also added a
way to mark a source file to `vtkm_unit_tests` as a source file that does
not contain its own test. Normally you would just compile all of the
tests together, select each with command line arguments, and use
duplicate `add_tests` for each argument. But that is not how
`vtkm_unit_tests` works, and it would be too hard to make that change.
The current ctest timeout in VTK-m are fine for the CI, but are too long for develoment when a test is hanging on a queued node. This commit allows a developer to turn off the majority of the hard coded timeout values which allows them to set them at the ctest command-line.
Added a name option that allows the same benchmark executable to be used
in multiple benchmark tests. This allows the benchmarks to be separated.
Also added an option to pass customized arguments to the benchmark
executable to overwrite the default values.
73cb38d86 Output complete list of libraries for external Makefiles
d87316fbf Create a list of all modules being built
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Nicole Marsaglia <marsaglia1@llnl.gov>
Merge-request: !2901
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.
When the configure modules were first created, there were some hacks
around filters that had not yet moved to the new filter mechanism. These
can (and should) be removed.
This mechanism sets up CMake variables that allow a user to select which
modules/libraries to create. Dependencies will be tracked down to ensure
that all of a module's dependencies are also enabled.
The modules are also arranged into groups.
Groups allow you to set the enable flag for a group of modules at once.
Thus, if you have several modules that are likely to be used together,
you can create a group for them.
This can be handy in converting user-friendly CMake options (such as
`VTKm_ENABLE_RENDERING`) to the modules that enable that by pointing to
the appropriate group.
This commit reflects the changes of VTK-m API/ABI release plans in
which we attempt ABI compatibility in patch releases.
- It also sets the version/soname for diy thirdparty module lib
The `vtkm_unit_tests` function in the CMake build now allows you to specify
which files need to be compiled with a device compiler using the
`DEVICE_SOURCES` argument. Previously, the only way to specify that unit
tests needed to be compiled with a device compiler was to use the
`ALL_BACKENDS` argument, which would automatically compile everything with
the device compiler as well as test the code on all backends.
`ALL_BACKENDS` is still supported, but it no longer changes the sources to
be compiled with the device compiler.
A compiler or linker may give an error if a .cxx file is empty (that is,
declares no symbols). This can happen if an instantiation declaration
gets removed during the compile either through preprocessor macros or
SFINAE.
To protect against this, declare a simple integer with a unique symbol
in each instantiation file. The overhead is very small and will prevent
compile/link errors.
Recently, an instantiation method was added to the VTK-m configuration
files to set up a set of source files that compile instances of a template.
This allows the template instances to be compiled exactly once in separate
build files.
However, the implementation made the assumption that the instantiations
were happening for VTK-m filters. Now that the VTK-m filters are being
redesigned, this assumption is broken.
Thus, the instantiation code has been redesigned to be more general. It can
now be applied to code within the new filter structure. It can also be
applied anywhere else in the VTK-m source code.