Generate VOL tests for h5copy

[mattjala]

• If a VOL connector is provided at build time, CMake will create counterparts of the h5copy tests for that connector, with names of the form HDF5_VOL_<vol_name>-<test_name>

• Add h5copy tests to the VOL workflows

The h5copy tests aren't added to the adios2 and the LOG VOL CI, because the workflows don't use fetchcontent to set up those connectors.

The h5copy tests are mostly disabled for the REST VOL because it doesn't factor in current working directory to the HSDS paths it accesses, so the h5copy tests fail due to being unable to find the files.

[Copilot]

Pull Request Overview

Adds support for generating VOL-specific h5copy tests in CMake and adjusts the REST VOL CI to skip h5copy tests due to HSDS path limitations.

• Introduces HDF5_GET_VOL_TGT_INFO macro in HDF5Macros.cmake to collect connector name, plugin path, and derive a clean VOL name.
• Updates .github/workflows/vol_rest.yml to exclude H5COPY tests on the REST VOL CI.

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
config/HDF5Macros.cmake	New macro to extract VOL connector properties and environment.
.github/workflows/vol_rest.yml	Excludes h5copy tests (H5COPY) from the REST VOL CI workflow.

Comments suppressed due to low confidence (1)

[fortnern]

Ideally we should find a way to get rid of the repeated code in the h5copy cmake file, but this looks good otherwise (as far as I can tell, I am not a cmake expert) and should be fine for now

[jhendersonHDF]

Similarly, we should probably avoid modifying any of these properties when using the native VOL. Currently, this seems like it would pass NONE for the environment, whereas we shouldn't be passing anything. It would also be good to avoid the generator expressions below that are trying to fix things up when using the native VOL.

[jhendersonHDF]

I think this is handy for preventing duplication of the ADD_ macros below, but it complicates the logic a bit when the native VOL is being used and has other issues due to VOL testing really being separate from regular testing. For example, tests that use VOL plugins should currently only be run when shared tools are built (or, the flipside of that, avoided when static tools are built), whereas the regular tools tests using the native VOL can always be run. I think it would go a long way if we were able to collapse the vast majority of the different ADD_ macros and ideally have one for regular testing and one for VOL testing, though it's not clear if that would be more complicated than what we currently have.

In the worst case, one alternative might be to move the foreach (VOL ...) logic into each of the macros so that we don't duplicate the calls here.

[mattjala]

If the primary motivation is to separate VOL testing from regular testing, does moving the per-VOL loop to inside the ADD_ macros make that any simpler? It seems like any conditions we want to enforce as requisite for VOL testing (e.g. shared libraries) are simpler to set up when all the ADD_ macros fall within a single loop.

The other case - where VOL tests are managed by an invocation of a counterpart ADD_VOL_ call for each ADD_ - seems cumbersome and likely to lead to newly added tests being accidentally left out of some test suites. The majority of tool tests can be run against most VOL connectors, so the default case being to run the test for native and non-native connectors makes sense.

I agree that it would be good to condense the number of distinct ADD_ macros, especially because they are duplicated across the different tools

[jhendersonHDF]

I would say the primary motivation is trying to separate VOL testing from regular testing while also trying to prevent the need for duplicating calls to the ADD_ macros, since, as you mention, it opens the possibility for someone to forget to add new calls for both the native VOL and external VOLs. Moving the foreach logic into each macro allows us to keep only one set of calls to the macros and allows us to easily separate the VOL-specific test setup logic from the logic for the native VOL; mixing logic between "regular" testing and external VOL testing is always going to be messy. However, it will likely make each of those macros substantially larger, which is why I think the ideal case is condensing the majority of the existing macros.

In many cases, the macro variants aren't substantially different from each other, so I think this is work that needs to happen regardless. The current situation of having many variants of tools test macros doesn't lend itself well to adding in VOL testing without either duplication or hacky workarounds for the native VOL.

The majority of tool tests can be run against most VOL connectors, so the default case being to run the test for native and non-native connectors makes sense.

As I recall, several tools tests had to be skipped or left out for the majority of VOL connectors the last time this was tested, so I'm not sure this is necessarily the case. And to me this is all the more reason to keep VOL testing as separate from regular testing as possible.