Apparently, this is compatible with older versions of cmake, while having the same effect. Apparently, the cmake people spent some time refuling to let people specify C++ standard versions and instead insisted that they specify specific features instead. They did not see the light until cmake 3.8, but that's too new for us to require yet, I guess.

I'm tired of working around missing features that were added in C++14. It's four years old now, compilers should support it.

An inconsistency was introduced with the previous fix to allow Cap'n Proto
installations in system directories to be found by CapnProtoTargets.cmake:
if the user installed Cap'n Proto in two locations, one of which is a
system directory, e.g. /usr and /somewhere/else, and set
PKG_CONFIG_PATH=/somewhere/else/lib/pkgconfig, the dependent project
would use headers from /somewhere/else/include, but libraries from /usr/lib.

This change resolves the inconsistency, allowing PKG_CONFIG_PATH to solely
control the location of the desired installation of Cap'n Proto.

It looks like pkg-config silently drops -I and -L flags pointing to
default directories:

```
$ cat /usr/lib/pkgconfig/capnp.pc
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: Cap'n Proto
Description: Insanely fast serialization system
Version: 0.7-dev
Libs: -L${libdir} -lcapnp -pthread  -lpthread
Libs.private:  -lpthread
Requires: kj = 0.7-dev
Cflags: -I${includedir} -pthread

$ pkg-config --libs capnp
-lcapnp -pthread -lpthread -lkj -pthread -lpthread
```

Ideally, however, we should use FindPkgConfig.cmake's own facilities
to generate IMPORTED targets from pkg-config files.

This file is obsoleted by the CMake config package files that the autotools build now installs. Since FindCapnProto.cmake contains an implementation of capnp_generate_cpp(), in which I just fixed a bug, this file seems like a maintenance liability  now, so I'd like to delete it.

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.

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.

These variables need to be cache variables or else the user can't override them on the command line (e.g. when building a project against a lite mode installation).

Closes #523.

Copied CMake's bundled AnyNewerVersion template to our local cmake/ directory, and modified both CMake and autotools scripts to configure/install it.

This completes the autotools installation of CMake config files, minus version compatibility checking.

This option was only useful when MSVC couldn't build the capnp command
line tools, so let's back it out.

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.

It is useful for autoconf based installations.

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.

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.

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.

The idea behind the directory organization was that we might have official implementations for other languages in other top-level directories, as siblings to the c++ directory. It seems implausible that we'd use CMake as a meta-build-system over all of these.

Another reason for this change is that the release tarball actually contains only the c++ subdirectory. We probably want to include cmake files in the release.