-
Notifications
You must be signed in to change notification settings - Fork 279
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
Fix setting CATKIN_GLOBAL_LIBEXEC_DESTINATION to libexec. #713
Conversation
The order of Also changing the variable I would recommend to not override the libexec destination since it is currently not well supported. May be a note should be added to the documentation to make this clear. |
Right, didn't think about that.
Could you please be more specific ? I've been using this for months without a single issue. |
If you would set |
Ah, yes indeed. Thanks. |
I tried to set CATKIN_GLOBAL_LIBEXEC_DESTINATION to libexec, as described as possible in doc/user_guide/variables.rst, since I find this location more natural for nodes & co. However, catkin_find could not find any node after that. This patch makes it possible to find nodes there, while maintaining the translation libexec -> lib.
Updated |
@@ -71,6 +71,8 @@ They only contain relative paths and are supposed to be relative to the ``${CMAK | |||
|
|||
This is set to ``lib``. | |||
On non-Debian distributions it could be set to ``libexec``. | |||
Note that setting this variable to anything but ``lib`` or ``libexec`` will | |||
not work as expected since the logic in the code expects one of these values. |
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.
Instead of:
since the logic in the code expects one of these values.
I would write it like:
since tools like ``catkin_find`` will only consider these two locations.
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.
agreed, updating it
…LIBEXEC_DESTINATION to values unknown to the Python code.
Thank you. Squashed and merged in a4b3a23. |
ros/ros#83 indicates a regression due to this PR. Extending The duplicated return in the updated test should have been a strong indicator of that: catkin/test/unit_tests/test_find_in_workspace.py Lines 63 to 64 in 37576a5
I have created #739 to address it. |
oh, indeed, sorry & thanks for fixing it i assumed the duplicated return was due to that search_dirs already contained 'lib', guess i was wrong |
I tried to set CATKIN_GLOBAL_LIBEXEC_DESTINATION to libexec, as described as possible in doc/user_guide/variables.rst, since I find this location more natural for nodes & co.
However, catkin_find could not find any node after that. This patch makes it possible to find nodes there, while maintaining the translation libexec -> lib.