Cryptoconditions provide a mechanism to describe a signed message such
that multiple actors in a distributed system can all verify the same
signed message and agree on whether it matches the description. This
provides a useful primitive for event-based systems that are distributed
on the Internet since we can describe events in a standard deterministic
manner (represented by signed messages) and therefore define generic
authenticated event handlers.
The cryptoconditions specification implemented is available at:
https://tools.ietf.org/html/draft-thomas-crypto-conditions-01
* Still respects "-Dtarget" unity/nonunity selection. Still defaults to
unity.
* Adds a new target (rippled_classic or rippled_unity) depending on
unity/nonunity selection.
* New target does not build by default.
eg. Use `cmake --build . -target rippled_classic`
* Copy all config variables (Debug/Release to DebugClassic/ReleaseClassic) for nonunity builds
* CI uses the more generic "cmake --build" command
* Simplify Travis APT config.
* Automatically retry Travis build and test script. Will result in fewer
false negatives.
* Travis install scripts use absolute paths.
* Build a library of cmake functions for reuse.
* Disallow cmake builds in project root.
* Disallow cmake default 32-bit Visual Studio builds.
* Add several missing nonunity / header files, including all unit tests to
cmake.
* Change gcc.debug.nounity Travis build to use cmake, instead of adding
builds.
* Change Appveyor build to cmake. Eliminates most spurious failures, which
are caused by python or scons failing to download.
cmake support in rippled. Currently supports:
* unity/nounity debug/release
* running protobuf
* sanitizer builds
* optional release build with assert turned on
* `target` variable to easily set compiler/debug/unity
(i.e. -Dtarget=gcc.debug.nounity)
* gcc/clang/visual studio/xcode
* linux/mac/win
* gcc 4 ABI, when needed
* ninja builds
* check openssl for acceptably recent release
* static builds
TBD:
* jemalloc support
* count
Notes:
* Use the -G"Visual Studio 14 2015 Win64" generator on Windows. Without
this a 32-bit project will be created. There is no way to set the
generator or force a 64-bit build in CMakeLists.txt (setting
CMAKE_GENERATOR_PLATFORM won't work). The best solution may be to
wrap cmake with a script.
* It is not possible to generate a visual studio project on linux or
mac. The visual studio generator is only available on windows.
* The visual studio project can be _either_ unity or
non-unity (selected at generation time). It does not appear possible
to disable compilation based on configuration.
* Language is _much_ worse than python, poor documentation and "quirky"
language support (for example, generator expressions can only be used
in limited contexts and seem to work differently based on
context (set_property can set multiple values, add_compile_options
can not/or is buggy)
* Could not call out to `sed` because cmake messed with the regular
expression before calling the external command. I did not see a way
around this.
* Makefile generators want to be single target. It wants a separate
directory for each target type. I saw some mentions on the web for
ways around this bug haven't look into it. The visual studio project
does support debug/release configurations in the same project (but
not unity/non-unity).
