This implements changes needed to make the cmake project work well when it is not the top level project and has been included with add_subdirectory.
This is needed to refer to the include directory when the cmake project is not
a top-level project (when it is included with add_subdirectory) because
${CMAKE_SOURCE_DIR}/include will no longer refer to the right location.
This is also nice because the variable can be used in the target_capnp_sources
function and simplify calls to that function.
Make changes needed to make the cmake project work well when it is not the top
level project and has been included with add_subdirectory:
- Avoid defining "tests" and "check" targets when project is not at the top
level to avoid clashes. Add new "mptests" and "mpcheck" alternatives instead.
- Rename "example" target to "mpexamples"
- Rename "util" target to "mputil"
- Export MP_INCLUDE_DIR variable to parent scope so target_capnp_sources()
function can work well there.
- Replace uses of CMAKE_SOURCE_DIR with CMAKE_CURRENT_SOURCE_DIR
- Reset INCLUDE_DIRECTORIES property so include_directories calls in the parent
project do not affect this project. This was causing errors because the
bitcoin core build was adding global include directories and causing its init.h
file to take precedence over local one.
25@@ -26,17 +26,32 @@ include("cmake/compat_config.cmake")
26 include("cmake/pthread_checks.cmake")
27 include(GNUInstallDirs)
28
29+# Set convenience variables for subdirectories.
30+set(MP_INCLUDE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/include")
31+if(CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
32+ set(MP_STANDALONE TRUE)
MP_STANDALONE variable might be replaced with PROJECT_IS_TOP_LEVEL.
31+if(CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
32+ set(MP_STANDALONE TRUE)
33+else()
34+ # Set MP_INCLUDE_DIR for parent directories too, so target_capnp_sources calls
35+ # in parent directories can use it and not need to specify include directories
36+ # manually or see capnproto error "error: Import failed: /mp/proxy.capnp"
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 add_subdirectory calls should not introduce any side effects in the call sites.
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 1103f86cd96238903ae1c01c8af4bb672079d5c0 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.