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

Location of data directories for the tests #512

Open
ianmccul opened this issue Nov 21, 2024 · 7 comments
Open

Location of data directories for the tests #512

ianmccul opened this issue Nov 21, 2024 · 7 comments

Comments

@ianmccul
Copy link
Contributor

I have been attempting to run the test infrastructure locally. Most of the tests are failing with errors like

invalid file path for load. >> ../../tests/test_data_base/common/BlockUniTensor/OriginalBUT.cytnx

With some more investigating, I determined that it is running this code from the directory /home/ian/build/cytnx/tests. That is a subdirectory of my build directory, which is fine - but I have no idea why it would think that the .cytnx files would be located two directories up from there. I guess it should be looking in the source directory.

I have no idea what is different about my setup, I guess maybe people are using a build directory that is inside the source directory?

@ianmccul
Copy link
Contributor Author

fix in #513

@IvanaGyro
Copy link
Collaborator

This issue is related to issue #452 and PR #457.

@ianmccul
Copy link
Contributor Author

Ahh OK, it seems #513 is then just an alternate solution to #457. I was working from master, so I didn't realize there was already a fix in another branch. But I think #513 is the better solution? The tests should run out of the build directory, rather than the source directory. With #513 they could run from wherever you want, because the tests have the absolute path to the test data directory.

@ianmccul
Copy link
Contributor Author

So which tree is the actual current development tree? Which tree should I base PR's from?

@pcchen
Copy link
Collaborator

pcchen commented Nov 24, 2024

I think the current practice is to use dev-master for the PR. After we merge several PRs and make sure everything is OK, then we merge dev-master into master and (optionally) make a binary release.

@IvanaGyro
Copy link
Collaborator

I am fine with #513, but it conflicts with dev-master now.

@ianmccul
Copy link
Contributor Author

I'll redo the PR based on dev-master

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

No branches or pull requests

3 participants