Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmake: submodule data & working directory #2837

Open
Lestropie opened this issue Mar 1, 2024 · 0 comments
Open

cmake: submodule data & working directory #2837

Lestropie opened this issue Mar 1, 2024 · 0 comments
Assignees
Labels

Comments

@Lestropie
Copy link
Member

Prior to cmake (#2689), the two git submodules for test data are stored at testing/binaries/data and testing/scripts/data. The run_tests script would (if necessary) pull the data from the corresponding repo, and for each test, it would change the working directory to that location; this makes filesystem paths within the test scripts as simple as possible, though results in pollution with temporary files if one is not careful.

Following #2689, it seems that despite the execution of tests now being done from inside a cmake build directory using the ctest command, it is nevertheless the case that the working directory in from which each test is executed is still testing/*/data; that is, back with the source data and not exclusively within the build directory.

IMO it would be more appropriate if, every time cmake is run in build mode, provided the relevant configuration flag was specified to enable tests in the destination build directory, the versions of the two submodules pointed to in the source code were downloaded into the testing/ subdirectory of the cmake build directory.

(We could also discuss whether it would be appropriate to merge these into a single repository; since in cmake-land I think it would be expected that, if tests are enabled for any given build directory, it should be possible to run those tests after build time without any further modification of the build directory contents, which means it would have to download all data from both repositories, regardless of what tests one might be intending to run.
Unless we had separate configuration environment variable flags for enabling unit tests / binary tests / script tests, I suppose... but I don't think it'd be worth the effort myself)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants