xref: /aosp_15_r20/external/libwebsockets/READMEs/README.cmake.md (revision 1c60b9aca93fdbc9b5f19b2d2194c91294b22281)
1*1c60b9acSAndroid Build Coastguard Worker# Tips about CMake
2*1c60b9acSAndroid Build Coastguard Worker
3*1c60b9acSAndroid Build Coastguard Worker## Don't be afraid to nuke your build dir
4*1c60b9acSAndroid Build Coastguard Worker
5*1c60b9acSAndroid Build Coastguard WorkerCMake likes to cache options and other things in the build dir... if you stop
6*1c60b9acSAndroid Build Coastguard Workerasserting the state of something like `-DMY_OPTION=1`, then the last way it was
7*1c60b9acSAndroid Build Coastguard Workerset it cached.  On order to keep track of what you have set and not set, it's
8*1c60b9acSAndroid Build Coastguard Workervery advisable to explicitly keep all your options and set them all on one cmake
9*1c60b9acSAndroid Build Coastguard Workerline.
10*1c60b9acSAndroid Build Coastguard Worker
11*1c60b9acSAndroid Build Coastguard WorkerThen, when you meet a situation you changed something but somehow cmake is
12*1c60b9acSAndroid Build Coastguard Workersticking with what it knew before, you can fearlessly delete your build dir
13*1c60b9acSAndroid Build Coastguard Workerand create a new one with your explicit config.
14*1c60b9acSAndroid Build Coastguard Worker
15*1c60b9acSAndroid Build Coastguard WorkerOn Linux, it's usually enough to delete `CMakeCache.txt` to trigger it to config
16*1c60b9acSAndroid Build Coastguard Workerfrom the start again, but on, eg, windows, it isn't, for whatever reason it
17*1c60b9acSAndroid Build Coastguard Workerliterally needs the build dir removing.
18*1c60b9acSAndroid Build Coastguard Worker
19*1c60b9acSAndroid Build Coastguard Worker## CMake presence tests that fail
20*1c60b9acSAndroid Build Coastguard Worker
21*1c60b9acSAndroid Build Coastguard WorkerLws makes use of various CMake features to figure out what apis your libraries
22*1c60b9acSAndroid Build Coastguard Workeroffer, eg, OpenSSL has many different apis based on version, lws knows how to
23*1c60b9acSAndroid Build Coastguard Workerwork around most of the changes, but to do it it must find out what apis are
24*1c60b9acSAndroid Build Coastguard Workeravailable first on your build environment.
25*1c60b9acSAndroid Build Coastguard Worker
26*1c60b9acSAndroid Build Coastguard WorkerCMake basically builds little throwaway test programs using each api in turn, and
27*1c60b9acSAndroid Build Coastguard Workerif it builds, it understands that the api was available and sets a preprocessor
28*1c60b9acSAndroid Build Coastguard Workersymbol that's available in the main build accordingly.  Then we can do `#if xxx`
29*1c60b9acSAndroid Build Coastguard Workerto figure out if we can use `xxx` or need to do a workaround at build-time.
30*1c60b9acSAndroid Build Coastguard Worker
31*1c60b9acSAndroid Build Coastguard WorkerThis works very well, but unfortunately if the program didn't build, there are
32*1c60b9acSAndroid Build Coastguard Workermany possible ways for the build to break even if the api being tested is
33*1c60b9acSAndroid Build Coastguard Workerreally available... for example, some library in your toolchain isn't being
34*1c60b9acSAndroid Build Coastguard Workerlinked for the throwaway test program.
35*1c60b9acSAndroid Build Coastguard Worker
36*1c60b9acSAndroid Build Coastguard WorkerWhen this happens, cmake indicates that apis that must be available are not available...
37*1c60b9acSAndroid Build Coastguard WorkerCMake keeps a log of what happened with the failed test programs in
38*1c60b9acSAndroid Build Coastguard Worker`./build/CMakeFiles/CMakeError.log`.  This is appeneded to, so the best way is blow
39*1c60b9acSAndroid Build Coastguard Workeraway the build dir and reconfig a new one from scratch, and go look in there to
40*1c60b9acSAndroid Build Coastguard Workerfind out what the compiler or linker was complaining about.
41*1c60b9acSAndroid Build Coastguard Worker
42