add safe-guards to allow octree headers only if octomap enabled #136
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
octomap is no header-only dependency and there is a hard-coded value in the
internal config.h header that specifies whether it is available or not. This
value influences the behavior of fcl headers
(include/fcl/traversal/traversal_node_setup.h) and it influences which methods
are available in the library
(src/broadphase/broadphase_dynamic_AABB_tree.cpp) Using these interfaces even
though fcl was configured without octomap invites trouble and should be
prevented.
Problems arise if fcl is not compiled with octomap but some version of octomap
is available at compile time of a dependent project. Basically this is the
case with libfcl in ubuntu xenial
(it was compiled without octomap support) and ros kinetic's octomap 1.8. I
expected to find errors on fcl not being configured with octomap but instead
only got compile issues because of interface changes.