fix make distcheck problem in dap4_test (but turning off nczarr_test/run_scalar.sh due to issue)

[edwardhartnett]

Fixes #2544
Fixes #2547
Fixes #2548

Had to turn off nczarr_test/run_scalar.sh

Also turn on distcheck target in CI build.

See #2545

[edwardhartnett]

When I run this branch through my Jenkins server it builds well for all supported versions of HDF5, with and without zstd, and with and without szip. So that's good!

Parallel testing next...

[WardF]

The addition of the DISTCHECK_CONFIGURE_FLAGS is great information, thanks! We'll want to keep the organization we have where build tests and run tests are separate steps in the workflow, for consistency.

[edwardhartnett]

Well I'm not sure how that can be done with the distcheck target.

The distcheck target makes a dist, unpacks it, builds it (outside the source directory) and runs make check, all in one step.

So I don't know how we can build tests in one step and run them in another...

[DWesl]

The main use of the distcheck target over the check and installcheck targets, in my understanding, is checking whether the project

1. Builds from a source distribution, not just from a repository
2. Can perform behaviors expected of Autotools packages, namely an out-of-tree build.
3. uninstalls and cleans up properly (make uninstall and make distclean).

If you can add a single run of make distcheck that only runs if all the Autotools runs of make check succeed, that should complete all objectives.

Another way to complete the second objective within the current framework is to perform all of the build and test steps in a subdirectory (i.e., start the configure step with mkdir build; cd build, and start every subsequent step with cd build).

It would also be possible to start the Linux Autotools runs with make dist, upload the resulting distributions, and use those instead of actions/checkout for getting the source code in later steps, which would achieve the first objective.

The make distclean check is easy with the out-of-tree build (if there's any files there, it's not in the state it was before ../configure) and should be straightforward with an in-repository build (fiddle with git status and friends until it tells you if there are any files not checked in, then check that the only new files are configure, Makefile.in, and friends).

[edwardhartnett]

OK, has this all been fixed in other ways?

SHould I just close this PR?

[WardF]

@edwardhartnett I believe it can be closed, thanks!