Add CMake build system

[Lekensteyn]

This PR adds CMake support as discussed in #448. Advantages over autotools build include:

• Faster configuration step (see below) and iterative builds (esp. with Ninja)
• Full out-of-tree build support without cluttering source tree (with files such as configure, Makefile.in, etc.)
• In theory easier support for Windows (only tested for the library with CUnit tests, not the examples or programs).
• No static library is built nor installed, reducing the time required for make check (see below for times)

Notes related to CMake:

• Only numeric versions are supported, hence the version is reported as 1.8.90 instead of 1.9.0-DEV.
• libev 4.11 (instead of 4.15) seems to work too, the README and CMakeLists.txt file have been updated to reflect this (any reason why it said 4.15 before? Travis uses 4.11...).
• Warnings are enabled by default (-DENABLE_WERROR=1 will additionally add -Werror). Additionally, -Wunused-macros and -Wstrict-prototypes are correctly detected (autotools fails because of crap tests).
• The check target is missing if cunit is not availble. Could be changed to a dummy target though.
• CMAKE_BUILD_TYPE=RelWithDebInfo is set which adds -g -O2 -DNDEBUG (disables assertions too!).

Notable modifications to non-cmake files (git rebase master && git diff --diff-filter=M master..):

• .gitignore: added cmake stuff
• .travis.yml: added cmake+gcc/clang besides autotools+gcc/clang
• **/Makefile.am: added cmake-related files to EXTRA_DIST
• integration-tests/setenv.in, python/setup.py.in: added cmake-compatible libdir

distcheck is passing with this branch + #542 included (see https://travis-ci.org/Lekensteyn/nghttp2/builds/115968744), cmake can be built from the tarball.

---

Above build benchmarks were done with this script on 4d801cd, times are based on the mean of the real times, standard deviation is insignificant:

#!/bin/sh
set -u -e
git clean -xfd
autoreconf -vifs
l=logs
mkdir $l
cm='cmake -DCMAKE_C_FLAGS="-g -O2" -DCMAKE_CXX_FLAGS="-g -O2"'
for i in {1..3};do
    r='&& mkdir $_ && cd $_ && time '
    script -c "rm -rf b$r $cm         .. && time make -j10 all check" $l/make-${i}.log
    script -c "rm -rf c$r $cm -GNinja .. && time ninja     all check" $l/ninja-${i}.log
    script -c "rm -rf a$r ../configure   && time make -j10 check" $l/auto-${i}.log
done

times for the check target with cunit installed (n=3):

what	mean	stdev
ninja-config	7.49	0.020
make-config	8.10	0.045
auto-config	10.05	0.104
ninja-build	27.75	0.274
make-build	30.99	0.032
auto-build	30.59	0.196

FWIW, make/ninja install takes 34ms, 500ms and 991s respectively.

[Lekensteyn]

@tatsuhiro-t In 9218d5d you added AC_HEADER_ASSERT "for benchmark", what benchmark? That option has as side-effect that the --disable-assert option becomes available.

In this PR, assertions are disabled by default (because CMAKE_BUILD_TYPE=RelWithDebInfo does so). To keep assertions and have debug info, use CMAKE_BUILD_TYPE=Debug (which is different from autotools in the sense that -O2 is not added).

When asserts are disabled, there are some warnings...

lib/nghttp2_session.c: In function ‘nghttp2_session_get_remote_settings’:
lib/nghttp2_session.c:6767:1: warning: control reaches end of non-void function [-Wreturn-type]

src/h2load_http2_session.cc: In member function ‘virtual void h2load::Http2Session::on_connect()’:
src/h2load_http2_session.cc:176:7: warning: variable ‘rv’ set but not used [-Wunused-but-set-variable]

...

Should assertions always be enabled, even for release builds?

[tatsuhiro-t]

Thank you for PR, I'll review this tomollow (I have a software release in another project today).

For assertions, I personally think its effect on performance in practice is negligible, so they should be enabled by default to give us useful debugging information. FYI, autotools can use -O2 and assertion enabled at the same time.

[Lekensteyn]

I also think that assertions are still useful in release builds, but the default cmake logic is apparently to disable them (that is, when you use -DCMAKE_BUILD_TYPE=Release). If you set -DCMAKE_BUILD_TYPE=None -DCMAKE_C_FLAGS="-g -O2" -DCMAKE_CXX_FLAGS="-g -O2" you get the same result as autotools.

Should I unconditionally enable assertions for various CMAKE_BUILD_TYPE values or add an option for this (-DENABLE_ASSERT=1|0, mirrors --enable-assert/--disable-assert from autotools). I tend to prefer the former option.

[tatsuhiro-t]

I also prefer the former.

[tatsuhiro-t]

PR looks good.

[Lekensteyn]

The assertions are fixed now (well, except on Windows where you have to define DEBUG explicitly for assertions).

Speaking of Windows, the library can now be built on Windows (tested with cmake && cmake --build). This only gives three warnings (vsnprintf usage and missing return because assertions were disabled). The main and failmalloc tests also run. Build log: nghttp2-v1.8.0-141-g08c7656-cmake-win7.txt (have a look, on_stream_close_callback uses uint32_t error_code which should probably be the nghttp2_error_code)

All dependencies are missing on Windows, so I had to hack a bit to get stuff working:

• CUnit: autoreconf -vifs && ./configure && ln -s . CUnit/Headers/CUnit on Linux for the headers, build libcunit.lib with MSVC2013. Set -DCUNIT_LIBRARY="\CUnit-2.1-3\VC9\Debug - Static Lib with MEMTRACE\libcunit.lib" -DCUNIT_INCLUDE_DIR=\CUnit-2.1-3\CUnit\Headers
• zlib: extracted http://zlib.net/zlib128-dll.zip to \zlib128 and added -DZLIB_ROOT=\zlib128
• OpenSSL: took 1.0.1r from http://www.npcglib.org/~stathis/blog/precompiled-openssl/, add -DOPENSSL_ROOT_DIR=\openssl-1.0.1r-vs2013
• Libev: patch for timeval+cmake (https://gist.github.com/Lekensteyn/e4586370b36d7b76d932), then simply build with cmake && cmake --build . and finally add -DLIBEV_LIBRARY=\libev-4.22\Debug\ev.lib -DLIBEV_INCLUDEDIR=\libev-4.22

Unfortunately I could not get the app to compile. The headers getopt.h and sys/un.h are missing (via utils.h) and template.h blows up completely.

Nevertheless I think that the cmake build is ready to go, others can add more Windows as desired. NOTE: only a static nghttp2.lib file is built, no dll.

[tatsuhiro-t]

LGTM. Compiling applications on Windows are known issue, currently they are *nix centric.

[tatsuhiro-t]

Merged now. Thank you for your awesome work!