Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
[Build][Docs][CI] BUILD_FUNCTIONAL_TESTS=False by default #557
[Build][Docs][CI] BUILD_FUNCTIONAL_TESTS=False by default #557
Changes from 1 commit
5cba9ef
b92512f
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
I agree that this extra Netlib dependency causes problems for unexperienced users, so it makes sense to disable it, but I think we still need some default validation to make sure the build is fine. As far as I know extra dependency is a problem only for BLAS and LAPACK, does it make sense to keep testing for other domains since they don't have extra dependencies? And for BLAS/LAPACK we can come up with more light-weight testing in the future.
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.
Are you talking about a default validation for unexperienced users? The examples are still built by default and don't require any external dependencies. This should be enough to make sure everything built fine.
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.
I'm not sure I can agree that passed examples are enough to confirm that built oneMKL Interfaces functionality is fine, we cover just 1-2 functions per domain, only USM API and mostly Intel oneMKL CPU backend for compiler time dispatcher from the build and we do not check correctness which could be a tricky problem to catch in the application where this oneMKL Interfaces build will be used.
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.
I'm not saying the examples are enough to test all the functionalities, just that they are enough to show oneMKL built. The point of this PR is that we have seen users getting confused why they couldn't build oneMKL and the issue was due to the additional dependencies needed by the tests. This PR aims to clarify this and force the users to manually enable the tests if they want them.
I think this makes it easier for first time users.
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.
Gentle ping @mkrainiuk. What are your thoughts on this?
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.
I support the idea of disabling testing for BLAS and LAPACK for the first time users and come up with some light testing that won't require Netlib package in the future, but I don't understand why we need to disable testing for DFT, RNG, and spBLAS that have proper testing coverage by default and don't have any extra dependencies that might confuse users. Could you please clarify why it's required to change testing mode for these domains as part of Netlib dependency problem?
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.
It is much simpler for users and developers if a CMake option always has the same default value. Some people use CMake GUI tools which show all the options with the default value but this causes confusions when the value change due to another option. We would need to add some documentation to explain when the tests are enabled or disabled and hope users find it.
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.
That's true, in this case I don't think modifying common option will be the right solution, instead it will be better to change requirements for Netlib dependency in two specific domains, where it's used, we can make it optional and based on the Netlib availability enable/disable unit tests where Netlib is used (later on adding some tests where it's not used so they can be built without Netlib).
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.
To be more specific here is a draft with some quick changes for what I've proposed before as potential solution for Netlib dependency problem #577
Please let me know what do you think about this approach.
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.
That's a good idea. Your solution looks fine to me!