Deal with the case Boost_LIBRARY_DIRS is empty #1378
Conversation
deal with possible Boost_LIBRARY_DIRS empty case, which happens when I use a local compiled boost 1.71.0 installed to /usr/locl/lib
example/CMakeLists.txt
Outdated
| set_target_properties(calendar PROPERTIES LINK_FLAGS "-L${Boost_LIBRARY_DIRS}") | ||
| if (${Boost_LIBRARY_DIRS}) | ||
| set_target_properties(calendar PROPERTIES LINK_FLAGS "-L${Boost_LIBRARY_DIRS}") | ||
| endif() |
There was a problem hiding this comment.
How does this work? The calendar target needs to link to the Boost.DateTime and Boost.ProgramOptions libraries. Does it even make sense to build the calendar target if those libraries aren't there?
There was a problem hiding this comment.
This checks if Boost_LIBRARY_DIRS is set. I guess the local installation of @xuning97 doesn't include a CMake package. In other words, it relies on the compiler to find them. For calendar to not work in that case, it'd have to use modern CMake, which would mean linking against the Boost:: targets, rather than this manual manipulation of properties.
There was a problem hiding this comment.
I still don't get how Boost_FOUND can be true but Boost_LIBRARY_DIRS is empty.
There was a problem hiding this comment.
Maybe if it uses Boost CMake, assuming it doesn't set it.
There was a problem hiding this comment.
Searching for it in its organization turns no matches: https://github.com/search?q=org%3Aboost-cmake+Boost_LIBRARY_DIRS&unscoped_q=Boost_LIBRARY_DIRS.
There was a problem hiding this comment.
It is set by FindBoost.cmake, which is a standard part of every CMake install: https://github.com/Kitware/CMake/blob/master/Modules/FindBoost.cmake
There was a problem hiding this comment.
As stated in the link above for Boost CMake, the logic does use the installed Boost, which does not set Boost_LIBRARY_DIRS.
There was a problem hiding this comment.
There is no Boost_LIBRARY_DIRS in the cmake file shipped with boost sources.
https://github.com/boostorg/boost_install/blob/develop/BoostConfig.cmake
Even if -L/path/to/boost/lib is not specified, it's possible to complete the link as long as the boost libraries are in the standard lib path or specified by LD_LIBRARY_PATH.
But if Boost_LIBRARY_DIRS is empty, the link command becomes -L{empty input}, which leads to strange link error information.
example/CMakeLists.txt
Outdated
| @@ -33,6 +33,8 @@ if(RANGES_BUILD_CALENDAR_EXAMPLE) | |||
| message(STATUS "boost: ${Boost_LIBRARY_DIRS}") | |||
| target_compile_definitions(calendar PRIVATE BOOST_NO_AUTO_PTR) | |||
| target_compile_options(calendar PRIVATE -std=gnu++14) | |||
| set_target_properties(calendar PROPERTIES LINK_FLAGS "-L${Boost_LIBRARY_DIRS}") | |||
| if (${Boost_LIBRARY_DIRS}) | |||
| set_target_properties(calendar PROPERTIES LINK_FLAGS "-L${Boost_LIBRARY_DIRS}") | |||
There was a problem hiding this comment.
| set_target_properties(calendar PROPERTIES LINK_FLAGS "-L${Boost_LIBRARY_DIRS}") | |
| target_link_libraries(calendar PRIVATE Boost::date_time Boost::program_options) |
Based on the discussion on the line below, this is how it should look like. Discard the other changes.
There was a problem hiding this comment.
Not a master in this area, Can this type of change support older version of boost?
There was a problem hiding this comment.
What actually matter is the CMake support for the Boost targets, which were added in CMake 3.5. Range-v3 requires 3.6, so it's alright.
Use modern way to link with boost libraries, so there is no need to specify -L directly
|
Very nice, thank you. |
In some case Boost_LIBRARY_DIRS is empty, which happens when I use a local compiled boost 1.71.0 installed to /usr/locl/lib Instead, use modern way to link with boost libraries, so there is no need to specify -L directly
deal with possible Boost_LIBRARY_DIRS empty case,
which happens when I use a local compiled boost 1.71.0 installed to /usr/locl/lib.