- 01 May, 2017 5 commits
-
-
Kenton Varda authored
-
Kenton Varda authored
kj::Directory::list*() should return sorted lists to avoid non-determinism.
-
Kenton Varda authored
-
Kenton Varda authored
fix typos: complied -> compiled
-
Kenton Varda authored
* Announce 0.6 release on blog, and update site. * When pushing capnproto-next site, include future blog posts. * Deeper headings. * Linkify people's names to Github profiles, and finish sentence about JSON. * Link to exact second in JGC video.
-
- 30 Apr, 2017 8 commits
-
-
David Renshaw authored
-
Kenton Varda authored
-
Kenton Varda authored
-
Kenton Varda authored
-
Kenton Varda authored
-
Kenton Varda authored
-
Kenton Varda authored
-
Kenton Varda authored
Fix VS2017 ICE and add build matrix to appveyor.yml
-
- 29 Apr, 2017 13 commits
-
-
Harris Hancock authored
Update outdated comment, and require CMake 3.1, which allows us to take advantage of target_compile_features.
-
Harris Hancock authored
Projects which use Cap'n Proto require C++11, because they must be able to compile our headers. Old gcc defaults to C++98, forcing users to manually specify the -std=gnu++11 flag in their CMake projects. CMake 3.1 introduced the target_compile_features command which removes this necessity by automatically communicating the C++ standard level requirement to client projects. Specifically, if target `kj` requires a C++11 feature publicly, then all targets which link to `kj` will also require that C++11 feature, and get the -std=gnu++11 flag for free. If that target is a library, such as `kj-async`, and `kj-async` links publicly to `kj`, the requirement is also transitive to all targets which link to `kj-async`. Note that CMake's default behavior is to request compiler-specific extensions, such as those provided by the -std=gnu++11 flag. You must specifically opt out of these extensions. I'm not aware of any way to propagate this nuance in CMake, but added a check to at least prevent users from compiling Cap'n Proto without extensions. With this change, the c++/samples/CMakeLists.txt will build with MinGW with no change beyond requiring a later version of CMake.
-
Harris Hancock authored
This will break out MinGW, VS2015, and VS2017 builds into separate jobs. While they will still probably build in serial, we'll at least get better granularity on test results.
-
Harris Hancock authored
VS2015 only barely compiled ~NullableValue's noexcept specifier expression. VS2017 can't at all, so we're going with noexcept(false) for MSVC for now.
-
Harris Hancock authored
-
Kenton Varda authored
KJ Filesystem API
-
Kenton Varda authored
This reverts commit f836a5fc.
-
Kenton Varda authored
-
Kenton Varda authored
-
Kenton Varda authored
-
Kenton Varda authored
-
Kenton Varda authored
-
Kenton Varda authored
-
- 28 Apr, 2017 14 commits
-
-
Kenton Varda authored
Have AppVeyor run the tests.
-
Kenton Varda authored
-
Kenton Varda authored
I can only reproduce this failure on AppVeyor, but the test prints: capnp\rpc.c++:2886: exception = kj\async-io-win32.c++:399: failed: WSASend(): A request to send or receive data was disallowed because the socket had already been shut down in that direction with a previous shutdown call. I think this is because WSAESHUTDOWN was considered to be a "bug" exception rather than a "disconnected" exception. It is odd, though, that it doesn't happen when I run locally.
-
Kenton Varda authored
-
Kenton Varda authored
-
Kenton Varda authored
On Linux this cuts 56% off the run time of the fuzz test (aka 2.28x speedup). On Windows this makes it practical to run the fuzz test at all -- previously it was wayyyyyyy too slow.
-
Kenton Varda authored
-
Kenton Varda authored
-
Kenton Varda authored
-
Harris Hancock authored
-
Harris Hancock authored
While the VS2015 build no longer depends on the MinGW installation as an external capnp, I think testing the CMake MinGW build on Windows probably remains worthwhile.
-
Harris Hancock authored
This option was only useful when MSVC couldn't build the capnp command line tools, so let's back it out.
-
Harris Hancock authored
The previous solution used hard-coded paths which would have had to be special-cased for multi-configuration generators such as Visual Studio, which put binaries in individual Debug, Release, etc. directories.
-
Harris Hancock authored
-