Closed jphill4 closed 1 year ago
I doubt there is a (good) reason that WORKING_DIRECTORY
is set explicitly. The basic macro was contributed by users, and subsequently modified by me. My best guess is that it solved some issue at some point that was actually being caused by some other problem, or it could simply be CMake ignorance on my part.
I will try to implement this on the develop branch and check with a few other downstream projects.
Done. Will merge after CI tests pass. (Might not be until tomorrow ...)
Let me know if you need a release with this feature - otherwise I may let it live on develop
for the time being.
Thank you! This will work for me! However, you might also consider exposing the "CONFIGURATIONS" option from add_test as well, though this is less frequently used. It can be nice to split unit tests into a "fast" and "slow" set, or perhaps a "serial"/"parallel" set. Again, can be set after declaration if really needed.
OK - that's another aspect of CMake with which I have little experience.
Similar to #374, for symmetry with CMake's native add_test, we should be able to set WORKING_DIRECTORY, CONFIGURATIONS, etc. via the add_pfunit_ctest command, e.g.
It looks pretty straight forward to add these options to add_pfunit_ctest, but I note that WORKING_DIRECTORY is already explicitly set to ${CMAKE_CURRENT_BINARY_DIR} in the add_pfunit_ctest function. Is there a reason for setting this explicitly, and therefore a reason we should not allow the user to specify this option?
In my testing, the tests seemed to run fine if I updated the WORKING_DIRECTORY after the fact, e.g.