You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think it would make sense to feature-gate masonry's dependency on nv-flip, which is only necessary for screenshot-based testing and so should never be used in a real application. nv-flip brings a C++ library, increasing build time and complexity, and possibly influencing other aspects of the application build (e.g. whether the shared or static C++ standard library is used on Android).
The text was updated successfully, but these errors were encountered:
Agreed. The difficulty here is that Cargo doesn't allow having required features for testing. That being said, if we adopt an xtask pattern (which we probably want anyway to enforce nextest usage + with Kompari), we can kill two birds with one stone:
#[cfg(not(feature = "test"))]#[test]fnmust_use_xtask(){panic!("To run tests use `cargo xtask test`. This enables required libraries and ensures that GPU over-access doesn't cause spurious failures");}
That needn't necessarily block this, as we never actually use the test infrastructure externally anyway.
I think it would make sense to feature-gate masonry's dependency on nv-flip, which is only necessary for screenshot-based testing and so should never be used in a real application. nv-flip brings a C++ library, increasing build time and complexity, and possibly influencing other aspects of the application build (e.g. whether the shared or static C++ standard library is used on Android).
The text was updated successfully, but these errors were encountered: