fix: TEST_DL_PATHS to multi-args

[LecrisUT]

Description

As @daniel-slater mentioned in #2736, the issue was that TEST_DL_PATHS in CatchAddTests.cmake should be a multi-argument variable. I have tested it against a generator-expression input like:

	list(APPEND extra_args
			DL_PATHS "$<TARGET_RUNTIME_DLL_DIRS:test-suite>"
	)

example_run

I did not add proper tests to check for this issue because I couldn't find any functional tests that run ctest --build-and-test, and that would require some discussion on how to structure and place these.

Also note that there is a much cleaner approach by automatically adding TARGET_RUNTIME_DLL_DIRS, which I will try to do in another PR.

GitHub Issues

Closes #2736

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.20%. Comparing base (ed6ac8a) to head (2558001).
Report is 17 commits behind head on devel.

❗ Current head 2558001 differs from pull request most recent head a6627f8. Consider uploading reports for the commit a6627f8 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##            devel    #2825      +/-   ##
==========================================
+ Coverage   91.19%   91.20%   +0.01%     
==========================================
  Files         197      197              
  Lines        8374     8374              
==========================================
+ Hits         7636     7637       +1     
+ Misses        738      737       -1     

[horenmar]

Re tests: I am not sure whether the DL_PATHS property shows up under --show-only=json-v1. If the answer is yes, then we can just inspect the CTest configuration to see whether there are indeed multiple dl paths shown.

There is already a test that configures build, runs catch_discover_tests and then inspects the output from ctest, in tests/TestScripts/DiscoverTests/. This could be slotted in there easily.

[LecrisUT]

There is already a test that configures build, runs catch_discover_tests and then inspects the output from ctest, in tests/TestScripts/DiscoverTests/. This could be slotted in there easily.

Cool I can add the test-case there. By default I think it should be using 2 DLLs, unless we need to add a dummy library target. I think functional tests like that should use the built-in ctest --build-and-test since it can more easily forward the generator, compilers, etc. and does not require any installation of catch. A complex framework that can do all checks and everything would be how upstream CMake does it, but for this project a simple run and test ctest should be fine.

[horenmar]

I see you added the setting to the CMakeLists for the tests, but there is no check in the script that runs the test. Do you intend to pursue this further?

[LecrisUT]

It is partly implicitly added, i.e. by TARGET_RUNTIME_DLL_DIRS:tests should contain the DLL_DIRS for tests.exe and catch.dll. I did not double-check this though, but if I am wrong, we can fix it by adding a dummy lib.cpp and library target to link it to where we put a simple 1+1=2 test or something.