CMake configuration files are intended to be used by other projects to find the library. Specifically the CMake find_package command can use it to find all files related to the project.
The idea is to support 2 different CMake configuration files for Libevent. One if you simply build libevent that is generated for the build tree.
And a second one that is generated for an install target that will be installed on the system and point to where on the system the lib files and such can be find.
So for instance, in the build tree the config would set the cmake variable `LIBEVENT_INCLUDE_DIRS` to `/path/to/libevent/build/include`.
And for the system config it would be set to `/usr/local/include` (or whatever target the user chose when running cmake).
27bd9faf498b91923296cc91643e03ec4055c230 changed this behavior so that both configs would point to the system wide path `/usr/local/include`
This meant that projects just wanting to import directly for the build tree would fail.
This fixes following problems in shared library build:
* visibility=hidden was not enabled for gcc because of incorrect variable name
* test programs that need internal APIs caused link errors
We had cmake and autoconf tests for the inet_aton function... but we
never actually use it any more.
(The autoconf tests still use the callability of inet_aton to decide
whether we need to link against -lresolv)
Reported by Harlan Stenn.
On windows all tests will fail if EVENT_NOWIN32 is set, since then there
will be no backend available.
Question is if we should simply disable the environment variable check on
Windows, since there's only one backend available anyway?
On systems where a previous version of Libevent is installed we don't want the system version of the headers to be included before the ones in the build tree. This happened on my OSX system where I had an ancient version of Libevent installed. It would then load the incorrect event-config.h and fail because the system introspection macros weren't set properly.
Use lcov/gcov to gather coverage info for the tests (Only works with gcc/clang and make).
cmake -DEVENT__COVERAGE=1 -DCMAKE_BUILD_TYPE=Debug ..
make
make verify_coverage
Current coverage (run on debian):
Line coverage 79.1 % 10231 / 12939
Function coverage 86.1 % 933 / 1083
Windows does not have the "unset" command, but this doesn't matter since
the problem that requires us to use unset doesn't happen on Windows.
Also did some minor cosmetic changes, and dependcy changes.
This is more than for cosmetic purposes to match how it's done with autoconf.
Due to the fact that we use environment variables to turn off certain backends during the tests, simply running "ctest" or "make test" can result in failed tests.
This is because if you do "EVENT_NOEPOLL=yes && export EVENT_NOEPOLL" and then run the tests, when running the epoll tests, the EPOLL backend will be turned off. There is no way of unsetting an environment variable for a test in CMake, you can only set them. And since libevent simply checks if the environment variable is set (it doesn't check the actual value of it), this won't work.
So to remedy this, we create the "make verify" target that first unsets all the EVENT_NO* environment variables, and then runs ctest.
Also bumped the required CMake version from 2.6 to 2.8, since the set_test_properties(bla PROPERTIES ENVIRONMENT "SOME_VAR") requires 2.8
Added some explicit dependencies for the test programs to libevent, so they don't just fail if you try to run the tests without first doing "make"
Fix how the CMake project adds the tests using the different backends. At
first we tried to do it exactly as it's done in test/test.sh.
However, test.sh uses a special program test-init to decide if a given
backend is available or not before running the actual tests. Doing it this way
will not be possible using CMake. Since then we would have to have the
test-init executable compiled at the time we run CMake, to know what tests
we should add. (And since CMake generates the make/project files that
compiles the executables, there's a catch 22).
Instead of deciding what tests to run this way, we simply use the result
of the CMake system introspection (that figures out what backends are
available) to decide what backend tests to add.
