-
Notifications
You must be signed in to change notification settings - Fork 603
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
Virtual File System #462
Virtual File System #462
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, we might be able to use the C++17 stl Filesystem classes and save a bit of platform dependent effort here. However, in general I really like this approach you have working thus far.
Lemme know if you need any help.
If you have chance please add or groom tickets on the Vulkan Samples Framework Improvements board. Currently its mainly broad statements of what we may want but it would be great to add more and prioritise which areas need to be worked on - which are bad ideas and which are good.... For now i've just been working on cleaning up some of the peripheral stuff. If you would like to make an issue discussing how the C++17 filesystem can simplify this PR then id be all for it @gpx1000! |
Force pushed the test framework to framework/v2.0 so that I can use it on other branches. It works as expected as it has been used in multiple PRs now. This should be one of the last force pushes to the branch. |
02a5a20
to
7250496
Compare
test framework added to |
Wanted to give this a spin, bud oddly my project structure looks completely different using this PR, and no samples are generated that I could run: What I did:
Looking at the CI it does seem to have the same problem. Am I missing something? |
This is the correct behaviour. Making the framework changes propagate between every sample would be too much work and counter productive for reviewers (larger diffs) lots of manual testing. The framework/v2.0 branch has no samples or framework folder. The aim is to write tests and code for the parts of the framework which we deem need the most attention. The CI should then validate that the contribution works on a given system with the desired behaviour. Code should build and the tests should pass. The workflows for this are Build Project and Unit Test Project. The end goal for a sample is shown here #458. The new framework should be more of a sandbox of components that samples can be made from. In terms of Vulkan, most will stay the same with some exterior API changes to simplify things. This PR #471 shows how I write unit tests against Vulkan usage. Extremely experimental but a promising example. Although simple, PRs #469 and #470 show this process working fairly well. If you would like to build and run the unit tests locally you can use:
and
You can also run the test executables directly to see the catch2 output |
Thanks for the clarification. I think I get it now ;) This builds fine for me with VS2019 on Windows, and all tests pass. So this looks good to me. |
Merging with 1 approval |
Description
A small improvement on the previous virtual file system PR.
Added the RE2 library for better regex, the API is easier to use and it removes some of the compiler specific issues in C++ regex
StackError
Strings
VFS
Testing
vkb__register_test
vkb_tests
bundles all tests into the same compile target