Handling multiple FIND_PACKAGE calls in CMake

Question

I have a quick question about the FIND_PACKAGE function in CMake. I have a project which utilizes the point cloud library (PCL). PCL depends on Boost, and my project does as well. So, at the top of my CMakeLists.txt I have the following:

FIND_PACKAGE(Boost REQUIRED COMPONENTS program_options)

# Preserve project Boost required libraries
SET(Boost_PROJECT_LIBRARIES ${Boost_LIBRARIES})

FIND_PACKAGE(PCL 1.6 REQUIRED COMPONENTS common search)

My project utilizes the Boost.program_options library, and PCL needs several others. When FIND_PACKAGE(PCL ...) is run, it overwrites the previous ${Boost_LIBRARIES} with its own required libraries. I came up with a work around to save the Boost libraries needed by my project and then find the PCL package.

My question for the CMake gurus is there a better way to handle this sort of thing in CMake? Or, is this possibly a bug in either the FindBoost.cmake or FindPCL.cmake modules?

Bedspring

In my experience, this is your best option unfortunately. Unless you wanted to fix up the FindPCL.cmake module. Again, just my experience. – Sedda

If no find_package-option changed between two find_package commands (like setting BOOST_ROOT or something), then I think you're right - it is a bug – Division

Why not make a copy of FindPCL.cmake, "fix" it and use CMAKE_MODULE_PATH to have cmake find your version? – Forethought

Answer 1

The find package for Boost populates a local variable (Boost_LIBRARIES) with the libraries for the components you chose. It is perfectly safe to call

find_package(Boost REQUIRED COMPONENTS program_options)

(or anything else) right before you want to use it. This will ensure that the variable is populated correctly for your executable.

Several find modules take the approach of populating local variables with customized results for use in that directory/executable, while deferring most of the heavy-lifting to global cache variables. Qt, and the new VTK config code in 6.0 do the same, so you can conceivably have several different versions of Boost_LIBRARIES that depends on the most recent find_package call in the current scope.

Talishatalisman