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.

Implement KJ Filesystem API on Win32

Now that I know the actual reasoning behind the loop, I think it's not the best answer. Instead, we should retry removing the directory if it reports not-empty, but only a few times before we give up.

Yes, I'm using BTRFS now...

Windows symlinks really aren't meant to be treated like Unix symlinks, and we don't support creating symlinks anyway, so we don't even know if this code works...

Fix multiple problems with connect() on non-glibc-Linux:

1. Correctly set nonblocking flag *before* calling connect(). (On glibc-Linux, we create the socket already in nonblocking mode, so this was never an issue.)
2. FDs could be leaked if connect fails. (This applies to glibc-Linux too, although connect() would have to fail immediately without blocking, which is unusual.)

Add support for Own<void>.

It appears that MSVC treats the specialization of this templated constructor as if it were an overload, causing the selection of constructor to be ambiguous. It only does this if the second template parameter (the EnableIf) if present; otherwise the specialization works correctly.

As a work-around, I refactored the code to avoid specializing the constructor. Instead, we add a static method that encapsulates the differences, which the constructor calls.

Any Own<T> can be converted to Own<void> (or Own<const void>). The main purpose of this is to give someone a way to invoke an object's disposer without them having to know anything about the type.

Also CopyFile() doesn't preserve sparseness.

So, don't use UTF-8 literals when trying to represent invalid byte sequences. Just use standard string literals.

Without ASYNC_LIBS, capnp-test doesn't get linked with Winsock, which is needed.

Not sure how this ever worked.

I wrote these while working on Windows support but they apply to Unix too.

I started from a clone of the Unix version of filesystem-disk.c++, and modified from there. The changes are pretty invasive, so I don't think trying to share implementations would have worked well.

Mostly adding / changing comments. Also some tweaks to consider that Windows uses HANDLEs rather than file descriptors.