-
Notifications
You must be signed in to change notification settings - Fork 36
cmake: Support being included with add_subdirectory #136
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -26,17 +26,32 @@ include("cmake/compat_config.cmake") | |
include("cmake/pthread_checks.cmake") | ||
include(GNUInstallDirs) | ||
|
||
# Set convenience variables for subdirectories. | ||
set(MP_INCLUDE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/include") | ||
if(CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR) | ||
set(MP_STANDALONE TRUE) | ||
else() | ||
# Set MP_INCLUDE_DIR for parent directories too, so target_capnp_sources calls | ||
# in parent directories can use it and not need to specify include directories | ||
# manually or see capnproto error "error: Import failed: /mp/proxy.capnp" | ||
Comment on lines
+34
to
+36
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This comment does not clarify why the propagating a variable to the parent namespace is better than specifying "include directories manually". I think that the latter is better. I do think that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I do think specifying include directories is better in general. But I don't believe libmultiprocess exporting its own include path to callers and then requiring callers to pass that include path back to it is necessarily better. For example when you use a toolchain's cc command, the cc command will allow you to override the toolchain include paths and require you to specify your own include paths, but will not force you to specify the toolchain include paths. So I think the change in 1103f86 is reasonable and good simplification, but I'm also fine with reverting it or just updating the comment here. You can let me know what you prefer and of course a PR would be welcome. |
||
set(MP_INCLUDE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/include" PARENT_SCOPE) | ||
set(MP_STANDALONE FALSE) | ||
endif() | ||
|
||
# Prevent include directories from parent project from leaking into this one. | ||
set_property(DIRECTORY PROPERTY INCLUDE_DIRECTORIES "") | ||
|
||
# Generated C++ preprocessor defines | ||
configure_file(include/mp/config.h.in "${CMAKE_CURRENT_BINARY_DIR}/include/mp/config.h") | ||
|
||
# Generated C++ Capn'Proto schema files | ||
capnp_generate_cpp(MP_PROXY_SRCS MP_PROXY_HDRS include/mp/proxy.capnp) | ||
|
||
# util library | ||
add_library(util OBJECT src/mp/util.cpp) | ||
target_include_directories(util PRIVATE | ||
$<BUILD_INTERFACE:${CMAKE_SOURCE_DIR}/include> | ||
$<BUILD_INTERFACE:${CMAKE_BINARY_DIR}/include> | ||
add_library(mputil OBJECT src/mp/util.cpp) | ||
target_include_directories(mputil PRIVATE | ||
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include> | ||
$<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}/include> | ||
${CAPNP_INCLUDE_DIRECTORY}) | ||
|
||
# libmultiprocess.a runtime library | ||
|
@@ -50,7 +65,7 @@ add_library(multiprocess STATIC | |
${MP_PROXY_SRCS} | ||
${MP_PUBLIC_HEADERS} | ||
src/mp/proxy.cpp | ||
$<TARGET_OBJECTS:util>) | ||
$<TARGET_OBJECTS:mputil>) | ||
add_library(Libmultiprocess::multiprocess ALIAS multiprocess) | ||
target_include_directories(multiprocess PUBLIC | ||
$<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}/include> | ||
|
@@ -68,7 +83,7 @@ install(TARGETS multiprocess EXPORT LibTargets | |
PUBLIC_HEADER DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/mp COMPONENT lib) | ||
|
||
# mpgen code generator | ||
add_executable(mpgen src/mp/gen.cpp $<TARGET_OBJECTS:util>) | ||
add_executable(mpgen src/mp/gen.cpp $<TARGET_OBJECTS:mputil>) | ||
add_executable(Libmultiprocess::mpgen ALIAS mpgen) | ||
target_include_directories(mpgen PRIVATE $<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}/include>) | ||
target_include_directories(mpgen PUBLIC $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include> $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}>) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once the minimum required CMake version is bumped up to 3.21+, the
MP_STANDALONE
variable might be replaced withPROJECT_IS_TOP_LEVEL
.