-
Notifications
You must be signed in to change notification settings - Fork 6.3k
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
[many ports] Remove _find_package guards that break *_FOUND #12157
Conversation
@vicroms @ras0219 @ras0219-msft Could you please review this PR? Thanks. |
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.
LGTM -- as a bonus, would you consider adding a section to the maintainer's guide about this?
Wait, why? And why me? I don't see anything in there one way or the other right now. It just seemed to be a bit of a convention that broke things, but an ad hoc convention that wasn't formalized anywhere. |
Being the author of many of them, I can just say that during the very long history of #5169 the requirement of calling find_package only if user had not already defined an include dir or library symbol become requested. That huge PR was then split into many different PRs with very long history each, so I cannot link you the exact comment about it. |
Interesting. I was wondering about the genesis of this choice. Not knowing why it was set up this way in the first place made it hard to know if it would break anything. |
Other than me rebasing it, what's this PR waiting on? |
@endrift the PR testing to run. Once it runs, I'll merge it. |
Looks like this depends on yasm on osx, so we should wait for #11535 which adds yasm on osx. |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
…t#12157) * [many ports] Remove _find_package guards that break *_FOUND * [many ports] Fix incrementing version Co-authored-by: Jack·Boos·Yu <47264268+JackBoosY@users.noreply.github.com>
Describe the pull request
Several ports add guards before calling
_find_package
to prevent it from being called if a package's libraries and/or includes are in cache. However,*_FOUND
variables are not in the cache, and since calling find_package is generally expected to invoke the actualFind*.cmake
regardless, such guards are not only unnecessary (I'm not actually sure what the point of them was in the first place), but also break CMake lists using*_FOUND
if CMake is ever re-run (and MSVC loooooooooves to rerun CMake every 3 seconds).What does your PR fix? *_FOUND being missing if a package's libraries and/or includes are in cache
Which triplets are supported/not supported? Have you updated the CI baseline? No changes.
Does your PR follow the maintainer guide? Yes.