mirror of
https://libwebsockets.org/repo/libwebsockets
synced 2024-12-12 08:47:25 +00:00
42 lines
2.0 KiB
Markdown
42 lines
2.0 KiB
Markdown
# Tips about CMake
|
|
|
|
## Don't be afraid to nuke your build dir
|
|
|
|
CMake likes to cache options and other things in the build dir... if you stop
|
|
asserting the state of something like `-DMY_OPTION=1`, then the last way it was
|
|
set it cached. On order to keep track of what you have set and not set, it's
|
|
very advisable to explicitly keep all your options and set them all on one cmake
|
|
line.
|
|
|
|
Then, when you meet a situation you changed something but somehow cmake is
|
|
sticking with what it knew before, you can fearlessly delete your build dir
|
|
and create a new one with your explicit config.
|
|
|
|
On Linux, it's usually enough to delete `CMakeCache.txt` to trigger it to config
|
|
from the start again, but on, eg, windows, it isn't, for whatever reason it
|
|
literally needs the build dir removing.
|
|
|
|
## CMake presence tests that fail
|
|
|
|
Lws makes use of various CMake features to figure out what apis your libraries
|
|
offer, eg, OpenSSL has many different apis based on version, lws knows how to
|
|
work around most of the changes, but to do it it must find out what apis are
|
|
available first on your build environment.
|
|
|
|
CMake basically builds little throwaway test programs using each api in turn, and
|
|
if it builds, it understands that the api was available and sets a preprocessor
|
|
symbol that's available in the main build accordingly. Then we can do `#if xxx`
|
|
to figure out if we can use `xxx` or need to do a workaround at build-time.
|
|
|
|
This works very well, but unfortunately if the program didn't build, there are
|
|
many possible ways for the build to break even if the api being tested is
|
|
really available... for example, some library in your toolchain isn't being
|
|
linked for the throwaway test program.
|
|
|
|
When this happens, cmake indicates that apis that must be available are not available...
|
|
CMake keeps a log of what happened with the failed test programs in
|
|
`./build/CMakeFiles/CMakeError.log`. This is appeneded to, so the best way is blow
|
|
away the build dir and reconfig a new one from scratch, and go look in there to
|
|
find out what the compiler or linker was complaining about.
|
|
|