Skip to content
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

Improvements to the build system #4609

Merged
merged 6 commits into from
Feb 17, 2017
Merged

Conversation

intelfx
Copy link
Contributor

@intelfx intelfx commented Aug 20, 2016

These are various improvements to the CMake buildsystem directed towards "modern" packaging with CMake IMPORTED targets and config-mode find_package().

There are several bugfixes and a slight refactoring of the buildsystem which makes Caffe properly export its transitive dependencies ("usage requirements") to the library users.

Open questions:

  • most of the dependencies are made PUBLIC (i. e. the client programs will link to them). This mimics the previous behavior, but it might be worth to revise configuration. E. g. the BLAS libraries — do we really need to make clients link to them?

Tests done:

  • building as a static and shared library for GNU/Linux and Android, linking to a sample project.

…ted caffe target

This is the first step towards "modern" IMPORTED-targets-only CMake
setup. The find_package modules still need to be rewritten and upstreamed in
form of config exports where possible.
Despite Caffe itself does not use OpenMP, explicitly linking to OpenMP
should be done when one statically links to a BLAS library which uses
OpenMP internally and does not provide proper CMake imported targets
with proper dependencies (nobody this so far).
Rationale: these are duplicated in CMakeLists code, and they cannot be
removed from there because many definitions need to be exported to the
library clients. See issue BVLC#4625.
@shelhamer shelhamer merged commit 9bb1b9c into BVLC:master Feb 17, 2017
@shelhamer
Copy link
Member

Thanks for the build polish.

PUBLIC
$<BUILD_INTERFACE:${Caffe_INCLUDE_DIR}>
$<INSTALL_INTERFACE:include>)
target_compile_definitions(caffe ${Caffe_DEFINITIONS})
Copy link
Contributor

@willyd willyd Mar 17, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to the CMake release notes this command was added in 2.8.11. The root CMakeLists currently requires only 2.8.7.

$<INSTALL_INTERFACE:include>)
target_compile_definitions(caffe ${Caffe_DEFINITIONS})
if(Caffe_COMPILE_OPTIONS)
target_compile_options(caffe ${Caffe_COMPILE_OPTIONS})
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to the CMake release notes this command was added in 2.8.12. The root CMakeLists currently requires only 2.8.7.

@willyd
Copy link
Contributor

willyd commented Mar 17, 2017

@intelfx Looks like we should also bump the minimum CMake version from 2.8.7 to 2.8.12.

@severin-lemaignan
Copy link

severin-lemaignan commented Oct 17, 2017

@intelfx While moving toward 'modern' CMake is certainly laudable, IMPORTED targets are not yet very common and I'm sorely missing documentation/example on how to use them. Even the official CMake documentation does not help me much in that regard.

Could you provide examples (possibly in the documentation of CaffeConfig.cmake) showing how to integrate Caffe in a C++ CMake project?

Right now I'm here:

# [...]
find_package(Caffe) 
add_library(Caffe SHARED IMPORTED)
# [...]
add_executable(myapp src/myapp.cpp)
target_link_libraries(myapp Caffe)

This fails because the Caffe includes are not found (I should make clear that Caffe is not installed in /usr/local/ but in a different prefix -- Cmake found it and find_package(Caffe) succeeds).

Adding target_include_directories(replay_with_poses PUBLIC Caffe) before add_executable does not help as the target myapp does not exist yet; adding it after does not help either (headers not found at the add_executable step).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants