Conversation
brtnfld
left a comment
There was a problem hiding this comment.
add_executable placed outside if (H5PL_BUILD_TESTING) — minor
In both BITGROOM/example/CMakeLists.txt and BITROUND/example/CMakeLists.txt, the h5repack_floats_* executables are compiled unconditionally, even when H5PL_BUILD_TESTING=OFF. Unlike the example programs that live before the if (H5PL_BUILD_TESTING) block (which are independently useful), these generators serve no purpose outside of testing. Consider guarding them:
if (H5PL_BUILD_TESTING)
add_executable (h5repack_floats_bitgroom ${PROJECT_SOURCE_DIR}/h5repack_floats.c)
...
endif ()
avoid violating assumptions about the meaning of that variable elsewhere in the code.
The captured value references in the removed tests seem not reproducible across platforms which needs further investigation. Untill then, the h5dump value tests are removed.
BitGroom filter does not have platform-dependent value problem so this test can come back.
ccr_gbr() called log10()+floor() per value to decide how many mantissa bits to zero, but log10() differences (~1 ULP, allowed by the C standard) at floor() integer boundaries produce 1-bit-different stored output on different platforms (as indicated by tests using macOS BSD libm and Linux glibc).
Bitround ulp reproducibility
An early-return check that read uninitialized prc_bnr_xpl_rqr variable was removed from the BitRound filter.
The h5repack_floats_bit{groom,round} helpers were invoked directly with
add_test(COMMAND $<TARGET_FILE:...>); on Windows the loader could not
find the HDF5 DLL and reported STATUS_DLL_NOT_FOUND, cascading into
gen-input/ud_convert/h5dump test failures. Route the fixture through
runTest.cmake so PATH/DYLD_LIBRARY_PATH/LD_LIBRARY_PATH are set up
consistently across platforms.
|
@ajelenak just a note that the changed test files also exist under https://github.com/HDFGroup/hdf5_plugins/tree/master/BITGROOM/config/cmake/binex/example/testfiles, https://github.com/HDFGroup/hdf5_plugins/tree/master/BITROUND/config/cmake/binex/example/testfiles and I believe https://github.com/HDFGroup/hdf5_plugins/tree/master/config/cmake/binex/example/testfiles as well. Those are the ones that get used by binary testing, as opposed to testing of what's copied to a build directory. |
|
Okay, I will see what I can do. |
Create equivalent of the test files under BITGROOM/example/ and BITROUND/example/ in three "binex" mirror trees that test the plugins as if installed from a binary distribution.
Both plugins' ` callbacks remove themselves from the pipeline on
non-float datasets, so the previous shared h5repack_layout.h5 input (integer
data) caused the tests to silently apply nothing once the plugin path was
fixed in #238.
Each plugin now ships a small
h5repack_floatshelper thatgenerates a chunked dataset of non-integer floats, and two
h5dumpcheckson the post-repack output assert that the filter ID stays in the pipeline
(via the
-pHcommand options) and that the dumped values match the capturedquantized output (via a
.ddloutput).Closes #240.