chaincodelabs / libmultiprocess

C++ library and code generator making it easy to call functions and reference objects in different processes

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

capnp/schema.h not found on macOS 12.5.1 (Intel Mac)

Sjors opened this issue · comments

On latest master f85feff.

make
[ 14%] Building CXX object CMakeFiles/util.dir/src/mp/util.cpp.o
In file included from /Users/sjors/dev/libmultiprocess/src/mp/util.cpp:6:
/Users/sjors/dev/libmultiprocess/include/mp/util.h:8:10: fatal error: 'capnp/schema.h' file not found
#include <capnp/schema.h>
         ^~~~~~~~~~~~~~~~

I have capnp 0.10.2 via Homebrew.

% cmake ..
-- The CXX compiler identification is AppleClang 13.1.6.13160021
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE  
-- Looking for C++ include kj/filesystem.h
-- Looking for C++ include kj/filesystem.h - not found
-- Performing Test HAVE_PTHREAD_GETNAME_NP
-- Performing Test HAVE_PTHREAD_GETNAME_NP - Success
-- Performing Test HAVE_PTHREAD_THREADID_NP
-- Performing Test HAVE_PTHREAD_THREADID_NP - Success
-- Performing Test HAVE_PTHREAD_GETTHREADID_NP
-- Performing Test HAVE_PTHREAD_GETTHREADID_NP - Failed
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/sjors/dev/libmultiprocess/build

For comparison, I was able to make a depends build using bitcoin/bitcoin#10102 @ 05e236772da0ed9396ce269b5fe8384b0de8e775.

I should probably try to reproduce, but do you know if homebrew package installs the capnp/schema.h file? (https://github.com/capnproto/capnproto/blob/v0.10.2/c++/src/capnp/schema.h)

Could also help to see the compile command line with make VERBOSE=1

Yes it does:

% ls /usr/local/include/capnp      
any.h				endian.h			persistent.capnp		rpc-twoparty.h			schema.capnp.h
blob.h				ez-rpc.h			persistent.capnp.h		rpc.capnp			schema.h
c++.capnp			generated-header-support.h	pointer-helpers.h		rpc.capnp.h			serialize-async.h
c++.capnp.h			layout.h			pretty-print.h			rpc.h				serialize-packed.h
capability.h			list.h				raw-schema.h			schema-lite.h			serialize-text.h
common.h			membrane.h			rpc-prelude.h			schema-loader.h			serialize.h
compat				message.h			rpc-twoparty.capnp		schema-parser.h			stream.capnp
dynamic.h			orphan.h			rpc-twoparty.capnp.h		schema.capnp			stream.capnp.h

Verbose output:

% make VERBOSE=1
/usr/local/Cellar/cmake/3.24.1/bin/cmake -S/Users/sjors/dev/libmultiprocess -B/Users/sjors/dev/libmultiprocess/build --check-build-system CMakeFiles/Makefile.cmake 0
/usr/local/Cellar/cmake/3.24.1/bin/cmake -E cmake_progress_start /Users/sjors/dev/libmultiprocess/build/CMakeFiles /Users/sjors/dev/libmultiprocess/build//CMakeFiles/progress.marks
/Applications/Xcode.app/Contents/Developer/usr/bin/make  -f CMakeFiles/Makefile2 all
/Applications/Xcode.app/Contents/Developer/usr/bin/make  -f CMakeFiles/util.dir/build.make CMakeFiles/util.dir/depend
cd /Users/sjors/dev/libmultiprocess/build && /usr/local/Cellar/cmake/3.24.1/bin/cmake -E cmake_depends "Unix Makefiles" /Users/sjors/dev/libmultiprocess /Users/sjors/dev/libmultiprocess /Users/sjors/dev/libmultiprocess/build /Users/sjors/dev/libmultiprocess/build /Users/sjors/dev/libmultiprocess/build/CMakeFiles/util.dir/DependInfo.cmake --color=
/Applications/Xcode.app/Contents/Developer/usr/bin/make  -f CMakeFiles/util.dir/build.make CMakeFiles/util.dir/build
[ 14%] Building CXX object CMakeFiles/util.dir/src/mp/util.cpp.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++  -I/Users/sjors/dev/libmultiprocess/include -I/Users/sjors/dev/libmultiprocess/build/include -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk -std=gnu++17 -MD -MT CMakeFiles/util.dir/src/mp/util.cpp.o -MF CMakeFiles/util.dir/src/mp/util.cpp.o.d -o CMakeFiles/util.dir/src/mp/util.cpp.o -c /Users/sjors/dev/libmultiprocess/src/mp/util.cpp
In file included from /Users/sjors/dev/libmultiprocess/src/mp/util.cpp:6:
/Users/sjors/dev/libmultiprocess/include/mp/util.h:8:10: fatal error: 'capnp/schema.h' file not found
#include <capnp/schema.h>
         ^~~~~~~~~~~~~~~~
1 error generated.
make[2]: *** [CMakeFiles/util.dir/src/mp/util.cpp.o] Error 1
make[1]: *** [CMakeFiles/util.dir/all] Error 2
make: *** [all] Error 2

Thanks for the info @Sjors. I think I was able to reproduce the problem and fix the bug with:

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -52,7 +52,8 @@ capnp_generate_cpp(MP_PROXY_SRCS MP_PROXY_HDRS include/mp/proxy.capnp)
 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>)
+  $<BUILD_INTERFACE:${CMAKE_BINARY_DIR}/include>
+  ${CAPNP_INCLUDE_DIRECTORY})
 
 set(MP_PUBLIC_HEADERS
   ${MP_PROXY_HDRS}

The issue is that util.cpp depends on capnp headers, but the current build doesn't explicitly add the capnp include directory. On my system, the bug was hidden because I'm using a nix environment, and just adding the capnproto dependency to it seems to automatically set CMAKE_INCLUDE_PATH and NIX_CFLAGS_COMPILE to include the capnp include directory. But if I manually override these I see the same error you reported, and the fix above is necessary.

Also, this is a tangent, but initially I couldn't get target_include_directories to actually add the include path on my system because cmake would silently strip it out, I think because of the behavior described in target_include_directories ignores compiler include paths. But adding target_compile_options(util PRIVATE "-I${CAPNP_INCLUDE_DIRECTORY}") did work, and after I cleared the build directory and reconfigured, target_include_directories worked too.

@Sjors I think PR #82 should fix the problems you reported

@Sjors I think PR #82 should fix the problems you reported

As #82 has been merged, can this issue be closed now?