-
-
Notifications
You must be signed in to change notification settings - Fork 4.7k
PCLConfig.cmake - POP policy-stack before return() #2626
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
Conversation
Fix PCLConfig.cmake not clearing policy stack before invoking return().
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.
Thanks for the quick fix 👍
I'm sorry, I might have spoken too soon. You might actually be right on including the first one as well. If it is indeed a macro the script will return. When I check the script for invocations of Line 420 in f9cbe14
and Line 335 in f9cbe14
Both would be situations in which the configure stage would abort. The macro will at most be called once. I'll just remove your last commit and merge. |
Great, nice to be helpful 😏 |
7f7191a
to
9a805f0
Compare
This doesn't work for me on my OSX 10.14.2 Mojave.
When I remove all PUSH and POP it works
|
Please post the contents of your |
The content:
|
For me this script looks alright and push/pops are balanced. No idea what could cause problems for you. |
I was able to reproduce the issue with a very simple
Instrumenting
|
I think the problem is not related to how the
is causing an abrupt interruption of |
|
@fspindle thanks. PROJECT(test-general)
CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
cmake_policy(SET CMP0011 NEW)
find_package(PCL)
message("PCL_INCLUDE_DIRS: ${PCL_INCLUDE_DIRS}")
message("PCL_LIBRARIES: ${PCL_LIBRARIES}")
ADD_EXECUTABLE(test-general test-general.cpp) and see if it still fails? |
Introducing one of the following lines or both of them doesn't change the behavior. The issue remains.
These are the vars set by
and as you mention I found also that I have
but that Now an interesting point is that if I change the
you can see that
Note that introducing the following lines in the new
doesn't affect |
Right, if it wasn't for failure to find glew, I suppose everything would work smoothly. However, aren't this exact pull request accounting for this failure execution path? The interruption is not abrupt, when glew is not found we get into @fspindle I think the reason why calling Here is an excerpt from our GLEW finder script: pcl/cmake/Modules/FindGLEW.cmake Lines 43 to 55 in 72f41b6
If your
Perhaps this is the problem? Could you try to install |
Yes! And this is also worring me along the fact that the policy 11 is set to old. Would be nice to understand why this is happening. |
Installing |
Fix PCLConfig.cmake not clearing policy stack before invoking return().
Fixes #2625