All 3Ps include dirs are treated as SYSTEM, this will stop compilers
stop emitting warnings from those files and greatly helps having high
warning levels and not being swamped by warnings that come from
external libraries.
- Targets now define the appropriate c++ defines, no more hand magic needed for llstartup.cpp
- Switch cmakeflage to USE_xxx rather than xxx as it was before. I personally find the USE_X notion more intuitive and it follows how KDU is used.
- To be backward compatible OPENAL/FMODSTUDIO flag will be mapped to USE_OPENAL/USE_FMODSTUDIO
for example), the define it sets it used. The vrabiables it did set are
unused.
There is a case to probe for pulseaudio and this is the Linux volume
catcher. But for that it is only necessary to detect the system include
to get a few defines and functions
LEGACY_STDIO_LIBS (was only used for Windows)
PTHREAD_LIBRARY (only Linux)
LLDATABASE_LIBRARIES (that one was supposed for Linux, but never needed anyway)
This gets rid of the a few OS specific set and uses variables (which some even seemed mostly
duplicate like WINDOWS_LIBRARIES ans UI_LIBRARIES) and it also solves the problem of
having them to tack on every target, as of no they come as a transitive dependency from llcommon
but it's safer and saner to put the LL 3ps under the ll:: prefix.
This also allows means it is possible to get rid of that bad "if( TRAGET ...) return() endif()" pattern and rather use include_guard().
-Wno-unused-but-set-variable/-Wno-unused-variable moved from just Linux to also OSX (clang) as there's a lot of those
in the code where newer xcode complains. Fixing all those places is going beyond the scope of modernizing cmake.
this everythig was over the place how it was set, worse even with wrong
functions like:
- add_definitions( /arch:SSE2 )
- add_definitions(/WX)
Those are each options to cl, not definitons.
tree layout and how it should be relative to the source tree. This is not necessarily correct.
By using 'source' and constructiong the path relative to this directory we always get a correct
answer.
Nicky