mirror of
https://github.com/warmcat/libwebsockets.git
synced 2025-03-09 00:00:04 +01:00
docs: add notes on cmake
This commit is contained in:
parent
40803b3e0d
commit
90aa78f0a8
1 changed files with 41 additions and 0 deletions
41
READMEs/README.cmake.md
Normal file
41
READMEs/README.cmake.md
Normal file
|
@ -0,0 +1,41 @@
|
|||
# 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.
|
||||
|
Loading…
Add table
Reference in a new issue