Although the header files included in the official Windows SDK have
mixed case file names, MinGW opted to ship headers with entirely lower
case names.
Since the MinGW headers are often used when cross compiling Windows
binaries on Linux hosts, and Linux treats paths as case sensitive by
default, following the 'official' spelling breaks many cross build
setups.
Non-cross builds do not seem to be affected by using lower case file
names, and Microsoft also does not seem particularly consistent in the
way it spells header file names in e.g. documentation and sample code.
Therefore, this patch makes wepoll use lower case file names when
including Windows headers, regardless of whether MinGW or the official
SDK is used.
See also https://github.com/libevent/libevent/pull/1039
and https://github.com/stjepang/smol/issues/138.
Closes: https://github.com/piscisaureus/wepoll/pull/19
By doing this, it is no longer necessary to invoke `unused_var()` to
squelch compiler warnings about unused variables that are used only in
`assert()` calls. These `assert()` calls are removed by the preprocessor
in release builds, which causes these warnings.
This possibility got inadvertently removed in the big config refactor
(3ad20d7), which made building a shared library from the bundled source
distribution (as is done by e.g. vcpkg) impossible.
The old name was not really appropriate; this attribute should only be
used on variable declarations, while the definition of the same variable
needs to be tagged with 'WEPOLL_INTERNAL'.
It turns out that these static constructors declared with
`__declspec(allocate(".CRT$XCU"))` don't work if you try to link them
from a static library. With this patch we go back to passing
'leak-check.c' as an extra source file when compiling a test.
* Configuration is now done with files, instead of through command line
switches specified in CMakeLists.txt.
* Link tests with a static library instead of compiling individual
wepoll source files as part of the test executable. This should make
the CI run significantly faster.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.