PointCloudLibrary / PointCloudLibrary/pcl

[PCLConfig.cmake] macro(find_boost) is ignoring Boost_FOUND, BOOST_ROOT, overwriting Boost_USE_STATIC(_LIBS) and Boost_USE_MULTITHREAD

Open
#4,374 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

kind: bug module: cmake needs: feedback skill: cmake
Dominant language
C++
Stars
11.1k
Forks
4.7k
Avg merge
4d 10h
Merged PRs (30d)
6

Description

As of PCL Version 1.9.1, the find_boost macro in the PCLConfig.cmake is ignoring/overwriting several related settings.

  1. The installer doesn't guarantee an existing 3rdParty/Boost, since I can disable that option. Same potential issue with FLANN, Qhull and Eigen. Bug imo: checking for "3rdParty" directory to imply all 3rdParty libs are installed there. Each lib should individually checked if their specific directory exists.
 if(EXISTS "${PCL_ROOT}/3rdParty")
    set(PCL_ALL_IN_ONE_INSTALLER ON)

should be at least something like follows, with their respective uses:

 if(EXISTS "${PCL_ROOT}/3rdParty/Boost")
    set(PCL_ALL_IN_ONE_BOOST_INSTALLER ON)

 if(EXISTS "${PCL_ROOT}/3rdParty/FLANN")
    set(PCL_ALL_IN_ONE_FLANN_INSTALLER ON)

 if(EXISTS "${PCL_ROOT}/3rdParty/Eigen")
    set(PCL_ALL_IN_ONE_EIGEN_INSTALLER ON)

 if(EXISTS "${PCL_ROOT}/3rdParty/Qhull")
    set(PCL_ALL_IN_ONE_QHULL_INSTALLER ON)

Workaround: If I want to use my own boost libs (potentially already used by other projects), I have to remove the full 3rdParty directory and extrude the other libs to be found somewhere else by defining their *_ROOT as usual.

  1. As a follow up of 1. BOOST_ROOT is overwritten without checking if it's defined by the user. If the strategy is to prefer the AllInOne module in any case, this is not actually an issue if the module is properly checked for in 1. I would expect that "${PCL_ROOT}/3rdParty/Boost" is only added as hint.
### ---[ 3rd party libraries
macro(find_boost)
  if(PCL_ALL_IN_ONE_INSTALLER)
    set(BOOST_ROOT "${PCL_ROOT}/3rdParty/Boost")
  elseif(NOT BOOST_INCLUDEDIR)
    set(BOOST_INCLUDEDIR "C:/Program Files/Boost/include/boost-1_68")
  endif(PCL_ALL_IN_ONE_INSTALLER)
  # use static Boost in Windows
  if(WIN32)
    set(Boost_USE_STATIC_LIBS ON)
    set(Boost_USE_STATIC ON)
    set(Boost_USE_MULTITHREAD )
  endif(WIN32)
...

Workaround: see 1.

  1. A bit unrelated and not actually a bug: The static linking option above in PCLConfig.cmake is not actually used if boost has been found before without static linking and not defined the components.
    Example:
set(Boost_USE_STATIC_LIBS OFF)
find_package(Boost REQUIRED)
find_package(PCL 1.9.1 REQUIRED)

This will find my Boost lib because I didn't define the components, then it tries to get all PCL 3rdParties and will echo Searching for SYSTEM_LIBRARY_RELEASE: boost_system instead of Searching for SYSTEM_LIBRARY_RELEASE: libboost_system. This looks like cmake seems to ignore set(Boost_USE_STATIC_LIBS ON) of PCLConfig.cmake.

set(Boost_USE_STATIC_LIBS ON)
find_package(Boost REQUIRED)
find_package(PCL 1.9.1 REQUIRED)

This works and gives Searching for SYSTEM_LIBRARY_RELEASE: libboost_system also in the PCLs process of finding boost.

I hope this post at least helps others shorten their search on similar issues.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in PCLConfig.cmake at the find_boost macro and inspect how PCL_ALL_IN_ONE_INSTALLER, BOOST_ROOT, BOOST_INCLUDEDIR, and the Boost_USE_* settings are handled. Compare the 3rdParty/Boost, FLANN, Eigen, and Qhull checks with the reported examples and verify behavior when Boost has already been found. Done means user-provided settings are preserved and each bundled dependency is detected independently.

Written by the indexing model from the issue text.

Assessment

Tech stack
cmake, cpp
Domain
build-system
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.