- 21 Dec, 2017 1 commit
-
-
Harris Hancock authored
capnp_generate_cpp() needs to import two directories by default: the src-prefix directory which houses the .capnp files being compiled (under their canonical paths), and the capnp include directory which houses capnp/rpc.capnp, capnp/schema.capnp, etc. (This latter path will necessarily be different for build-tree usage versus install-tree usage.) Before this commit, instead of importing the src-prefix, we were importing CMAKE_CURRENT_SOURCE_DIR. Note that for capnproto's own compilation of test.capnp and friends, the src-prefix and capnp include directory will end up being the exact same directory. It turns out to be surprisingly difficult to de-duplicate them, however, because the capnp include directory is actually a CMake generator expression in order to deal with the build-tree versus install-tree issue mentioned above. So, for now, we pass two -I flags to the same directory. Alongside the fix in capnp_generate_cpp(), I fixed the usage of it in c++/src/capnp/CMakeLists.txt by setting CAPNPC_SRC_PREFIX correctly and removing the /capnp suffix hack from CAPNPC_OUTPUT_DIR.
-
- 20 Nov, 2017 1 commit
-
-
Harris Hancock authored
capnp_generate_cpp() checks that input schema files exist at configure-time, and reports a fatal error if they don't exist. However, the check prepended the value of CAPNPC_SRC_PREFIX to input file paths, which is the wrong thing to do: the input file paths should be checked as-is if they are absolute paths, and checked relative to the current source directory, NOT the value of capnp's src-prefix flag, if they are relative paths, in order to match the capnp tool's behavior. It turns out that it's easiest to just unconditionally convert the input file paths to absolute paths, then check the absolute path. The reason is that we can't even pass relative paths to the capnp command, anyway: capnp interprets relative path inputs relative to its working directory, which defaults to the build dir. For consistency with other CMake commands (add_library, add_executable, etc.), it makes most sense if relative file path inputs to capnp_generate_cpp() are interpreted relative to the current source directory. This means that relative path inputs need to be converted to absolute paths before being fed to capnp, which was done right after the faulty existence check. This commit fixes the issue by modifying the existence check to check the path only after it's been converted to absolute form. Closes #586.
-
- 07 Nov, 2017 1 commit
-
-
Harris Hancock authored
-
- 27 Apr, 2016 1 commit
-
-
Branislav Katreniak authored
-
- 19 Apr, 2016 2 commits
-
-
Branislav Katreniak authored
-
Branislav Katreniak authored
If CapnProto is part of cmake build, macro CAPNP_GENERATE_CPP uses in-build capnp tools. This change fixes `make check` target with cmake. All tests pass except 1: [ FAIL ] exception-test.c++:30: legacy test: Exception/TrimSourceFilename 1: /home/brano/src/capnproto/c++/src/kj/exception-test.c++:31: failed: expected (trimSourceFilename( "/home/brano/src/capnproto/c++/src/kj/exception-test.c++")) == ("kj/exception-test.c++"); Not sure how to fix the test without disabling it.
-
- 11 Apr, 2016 1 commit
-
-
Alex Richardson authored
This makes it a lot easier for CMake based projects to use Cap'n Proto. Example usage: find_package(CapnProto) capnp_generate_cpp(FOO_SRCS FOO_HDRS foo.capnp) add_executable(foo main.cpp ${FOO_SRCS}) target_link_libraries(foo CapnProto::capnp CapnProto::capnp-rpc) This is a lot better than the previous variable based solution since linking to nonexistent targets is an error whereas an empty variable expansion (e.g. due to typos) will be silently ignored. It also makes sure that the right compiler flags, include directories, defines and link libraries are passed to the compiler for that target without needing any other include_directories(), etc.
-