MSVC cannot compile the overloaded member function SFINAE technique used
in Kind_ and FromAny_. It has an easier time with std::void_t-style
SFINAE.

Code which relies on RPC clients and servers cannot compile in lite-mode.

Note that none of the FromAny static_asserts in common-test.c++ will
compile yet in MSVC. Nevertheless, the first three (FromAny<int>,
FromAny<Reader>, FromAny<Builder>) should reasonably work in lite-mode.

Stringification depends on the dynamic API, which is unavailable in lite
mode.

Thanks to @kentonv for the wording.

Fixes a spurrious test failure with out-of-tree builds.

Fixes #235
Closes #325

Was incorrect operator!= for Text::Builder

Add a cmake package config module + further cmake cleanups

It is useful for autoconf based installations.

Fix JSON handler for DynamicStruct. The handler needs to be told the struct's schema to construct an orphan.

Also improve error message when addTypeHandler() is given a handler for a dynamic type but no specific schema is specified. We could support this eventually but we don't presently.

Problem discovered and initial test case contributed by Harris Hancock.

miniposix.h shouldn't be executable

autotools build does not have this option.
Capnp tools are built when CAPNP_LITE == OFF

This reverts commit 945ec815.

Addressing review comments.

Noticed by rpmlint

Bka json inf nan as string

json: implement decode(... input, DynamicStruct::Builder output)

# Conflicts:
#	CONTRIBUTORS

Required by construct: export(EXPORT ..)

This allows to consumers to use the same targets regardless
whether capnproto CMakeList.txt is added as subdirectory
or whether capnproto is found as package

This dependency exists in Makefile.am

Build location is consistent with source and install location.

File CapnProtoConfig.cmake in build directory includes this file.
This change enables consumers to find package CapnProto
in build directory without installation.

Consumers of non-installed build directory don't have to manually
set include dirs.

Using installed capnp tools during instead of built capnp tools
easily leads to bad results.

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.

Which tools should the build system use in this case?

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.

Fixed access violation in GetFunctorStartAddress()

Trivial changes required to support Visual Studio 2015 Update 2

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.