Added ability to specify a root dir for boost-libs and curl. #361
Conversation
|
@asekretenko @greggomann : this is another improvement to cmake to be able to build with a custom location of boost-libs, curl and libseccomp. |
akornatskyy
changed the title
| if ("${BOOST_ROOT_DIR}" STREQUAL "") | ||
| EXTERNAL(boost ${BOOST_VERSION} ${CMAKE_CURRENT_BINARY_DIR}) | ||
| add_library(boost INTERFACE) | ||
| add_dependencies(boost ${BOOST_TARGET}) | ||
| if (CMAKE_CXX_COMPILER_ID MATCHES GNU OR CMAKE_CXX_COMPILER_ID MATCHES Clang) | ||
| # Headers including Boost 1.65.0 fail to compile with GCC 7.2 and | ||
| # CLang 3.6 without `-Wno-unused-local-typedefs`. | ||
| # TODO(andschwa): Remove this when Boost has a resolution. | ||
| target_compile_options(boost INTERFACE -Wno-unused-local-typedefs) | ||
| endif () | ||
| target_include_directories(boost INTERFACE ${BOOST_ROOT}) |
There was a problem hiding this comment.
Hmm actually I'm wondering.... should we do the same thing we do for curl and boost that we do for seccomp, and have a .cmake file which defines helpers for those libraries as well?
There was a problem hiding this comment.
cmake comes with FindCURL.cmake and FindBoost.cmake modules.
In case of boost we need only 5 lines of code:
if ("${BOOST_ROOT_DIR}" STREQUAL "")
...
else ()
add_library(boost INTERFACE)
target_include_directories(boost INTERFACE ${BOOST_ROOT_DIR}/include)
endif ()Shadowing FindBoost.cmake with our own version might not be a good idea due to a possible confusion, same applies to using a different name like FindBOOST.cmake. The default implementation is quite sophisticated (2.3K+ SLOC). Plus you don't really get rid of that if statement because it treats boost as an external project. With find_package you will get an extra line and you still need to use add_library, etc.
Same applies to curl, the only code we add is to make a call of FIND_PACKAGE_HELPER and adopt it response to one produced by default FindCURL.cmake.
In case of libseccomp, there was no default find module in cmake, thus it was reasonable to introduce one.
Taking above into account we might consider to get rid of FindLIBARCHIVE.cmake in favor of default one FindLibArchive.
No description provided.