- 28 Apr, 2017 1 commit
-
-
Harris Hancock authored
This option was only useful when MSVC couldn't build the capnp command line tools, so let's back it out.
-
- 17 Apr, 2017 1 commit
-
-
Harris Hancock authored
When building Cap'n Proto with compilers which can't yet build the command line tools (MSVC), the exported targets capnp_tool and capnpc_cpp don't exist, thus attempting to use them in a generator expression when setting CAPNP_EXECUTABLE and CAPNPC_CXX_EXECUTABLE causes a hard error. Leaving the variables unset provides users the opportunity to set CAPNP_EXECUTABLE and CAPNPC_CXX_EXECUTABLE manually in CMake projects consuming Cap'n Proto as a CMake package, and produces a less mystifying error message if the user forgets. Thanks to Philip Quinn for advice on this issue.
-
- 27 Apr, 2016 1 commit
-
-
Branislav Katreniak authored
-
- 19 Apr, 2016 1 commit
-
-
Alex Richardson authored
This fixes the lib vs lib64 vs lib32 issue when installing Other problem with cached BIN_INSTALL_DIR, LIB_INSTALL_DIR, etc options is that changing official CMAKE_INSTALL_PREFIX variable has no effect.
-
- 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.
-