-
Notifications
You must be signed in to change notification settings - Fork 44
Test all architectures during integration testing #881
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
base: main
Are you sure you want to change the base?
Conversation
|
This results in the following test failure on Bit32, Bit64 and Wide platforms
And these tests failed on Wide platform
|
|
I think some of our tests aren't implemented in a cross-platform way. Moreover, it's impossible (I think?) to run 32-bit programs in our test environment on Unix. I like the idea of running those on integration tests, but perhaps I'd take a more controlled and conservative approach: run the tests in this mode only on a select subset of the integration tests. Perhaps add suffixes to test files, like So that all tests run only on the default arch, but those few that are designed for portability run on other architectures as well? |
|
I’m not sure that our tests are written in “wrong” way. Struct.c is definitely wrong codegen which does not utilize CPtr. So for now I would verify that we don’t find codegen issues, and go for out if needed |
|
@kant2002 how would you prefer us to proceed? Which plan do you believe should be preferred here? |
|
To reduce churn in the code I think we should run all tests files without suffix on all platforms, and introduce suffix for architecture. That seems to be reasonably easy to do. Maybe we can have multiple suffixes, like |
|
I think the current tests are all portable between all the supported operating systems (and we actually run them), so no need in suffixes like This story is about Cesium-supported "architectures", right? And not each of tests turns out to be runnable on all operating systems when compiled under all the Cesium architectures. Then we can implement the following strategy.
Does this sound alright? |
|
Sounds like a good plan. I really want as much test running as possible, and |
Not sure this is a way I want it to be always, since it kills inner loop. But at least this is give us assesment
Alternative approach would be perform conditional magic, and teach Nuke to launch Integration tests with different combinations. Probably that's a way