fix PythonLibs include#45
fix PythonLibs include#45v4hn wants to merge 1 commit intoros-visualization:groovy-develfrom v4hn:fix-pythonlibs
Conversation
<PACKAGE>_FIND_VERSION seems to be unsupported in cmake 3.0. Also there is no reason for this variable in this case anyway.
|
Also please re-release this package with indigo to include the change. |
There was a problem hiding this comment.
Shouldn't this require an exact version match then?
find_package(PythonLibs "${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR}" EXACT REQUIRED)
There was a problem hiding this comment.
On Sat, Jun 21, 2014 at 05:28:25AM -0700, Dirk Thomas wrote:
Shouldn't this require an exact version match then?
find_package(PythonLibs "${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR}" EXACT REQUIRED)
That doesn't work over here at least.
That is because 2.7 != 2.7.7 and find_package detects
the latter one over here. If there is no extra flag available for that case,
I'd like to leave it that way.
|
I have committed a modified fix which also sets |
|
Thank you for your response and fix. Although I don't understand why you did not simply merge the request. |
|
Yes, I could have merged the PR first and then added the additional versions line separately. I simply committed them together since it keeps these kind of related changes in a single commit. It was also slightly faster to do it this way since I already had all the changes in my local working copy in order to test it. But anyway I don't see a real difference in both approaches. And setting the additional versions is by no means superfluous - it is simply not possible to only install a single Python version on most OS I have seen (e.g. Trusty). In order the specific the specific version which should be used (which might not be known to the PythonLibs CMake config file) it must be specified explicitly. |
|
Ok. It would be great to see this problem fixed in the upcoming indigo-release as well. |
|
This will be released to all active ROS distros: Groovy, Hydro and Indigo. |
_FIND_VERSION seems to be unsupported in cmake 3.0. Also there is no
reason for this variable in this case anyway.