-
-
Notifications
You must be signed in to change notification settings - Fork 4.6k
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
Add Boost CMake module #3731
base: master
Are you sure you want to change the base?
Add Boost CMake module #3731
Conversation
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.
You got the general idea but your solution still needs work. With the current approach you're breaking pcl's the config file. Downstream projects, like the tutorials job, are not configuring properly.
Have a look at what was done in #1421.
pcl_find_boost.cmake
, needs to be migrated into it's own FindBoost.cmake
module inside pcl/cmake/Modules
. That way it can be invoked in both stages: when compiling pcl and when configuring a downstream project.
Got what you are trying to say, was initially thinking of doing something like suggested but wasn't sure then. Will incorporate the changes suggested in the next commit. |
What's the idea behind setting separate variables like |
Consider these lines: Lines 321 to 325 in 2133857
We try to treat all external dependencies uniformly, thus the convention is that finder scripts set variables prefixed with capitalized name of the dependency. If it wasn't the case, we'd need to keep track of which library is called |
d18b9eb
to
e78a39d
Compare
Made the appropriate changes. I thought of using |
fdc9839
to
4c689b6
Compare
find_package(Boost 1.55.0 ${QUIET_} COMPONENTS @PCLCONFIG_AVAILABLE_BOOST_MODULES@) | ||
|
||
set(BOOST_FOUND ${Boost_FOUND}) |
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.
Would this stop overriding the Boost_LIBRARIES variable for anyone consuming PCL? There's an issue open (and verified) which says that find_package(Boost)
before find_package(PCL)
causes PCL to override the Boost libraries
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.
Also, what's the relationship of pcl_find_boost.cmake
with Modules/FindBoost.cmake
(because I notice it's untouched in this PR)
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.
Also, what's the relationship of
pcl_find_boost.cmake
withModules/FindBoost.cmake
(because I notice it's untouched in this PR)
That is to be removed.
Would this stop overriding the Boost_LIBRARIES variable for anyone consuming PCL? There's an issue open (and verified) which says that
find_package(Boost)
beforefind_package(PCL)
causes PCL to override the Boost libraries
Currently, no. It should be possible though to append the already existing found components to the list of found components.
Marking this as stale due to 30 days of inactivity. Commenting or adding a new commit to the pull request will revert this. |
Referenced in #2559.
Removed the replicated supported versions & cleaned up the modules section.
@SergioRAgostinho Is this what you had in mind?