Fix setting CATKIN_GLOBAL_LIBEXEC_DESTINATION to libexec.

[aballier]

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.

[dirk-thomas]

The order of search_dirs determines where resources are looked up first. Appending search_dirs_extra at the end would change the order and can therefore not be done as it is in this patch.

Also changing the variable CATKIN_GLOBAL_LIBEXEC_DESTINATION to anything else would not work since the Python logic does not know about that.

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.

[aballier]

The order of search_dirs determines where resources are looked up first. Appending search_dirs_extra at the end would change the order and can therefore not be done as it is in this patch.

Right, didn't think about that.
search_dirs.insert(search_dirs.index('libexec'), 'lib') should do it then (and be simpler)

Also changing the variable CATKIN_GLOBAL_LIBEXEC_DESTINATION to anything else would not work since the Python logic does not know about that.

Could you please be more specific ? I've been using this for months without a single issue.

[dirk-thomas]

If you would set CATKIN_GLOBAL_LIBEXEC_DESTINATION to e.g. foo the script catkin_find would still not work since it doesn't know about that path.

[aballier]

Ah, yes indeed. Thanks.
Will update the PR with the above fix + a doc patch.

[aballier]

Updated

[dirk-thomas]

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.

[aballier]

agreed, updating it

[dirk-thomas]

Thank you. Squashed and merged in a4b3a23.

[dirk-thomas]

ros/ros#83 indicates a regression due to this PR. Extending search_dirs should not be done in the workspaces loop but outside.

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

	'baz/lib/foo/foopath',
	'baz/lib/foo/foopath',

I have created #739 to address it.

[aballier]

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