* This doesn't change our minimum specs as we already required GCC 5, clang 3.4,
which fully support C++14. Interestingly only VS2015 is the odd one out but we
don't rely on any features from C++14 that it doesn't support.
3rdParty source files and some renderdoc files which include 3rdparty header files
Disable "-Wshorten-64-to-32" for the whole of qrenderdoc render_python.cxx triggers the warning
3rdParty source files and some renderdoc files which include 3rdparty header files
Disable "-Wshadow" for the whole of qrenderdoc render_python.cxx triggers the warning
It was previously marked as disabled for Apple
Required to build the python modules which are used by the testing framework
Python imports .so libraries by default, change the shared library extension to .so for python modules on Apple
* The main addition here apart from some extra stubs is a new rdc type
for date time objects.
* Although the module doesn't do anything and is only used for docs
reflection it is desirable to not have to link against Qt as this
can cause problems when linking the module without unresolved symbols.
* These .py wrappers are relevant for the non-builtin path, but since we
use -builtin they serve no purpose except to make things more complex.
* So instead we make the module directly exported as 'module' instead of
'_module'.
* On windows there's no conflict because we have renderdoc.dll vs
renderdoc.pyd. On linux it's librenderdoc.so vs renderdoc.so.
* To prevent supporting files like .lib / .pdb from conflicting on
windows we build the python modules into a subdirectory. They're not
ever used by the UI (it links in the bindings directly).
* Now you can build the python modules without building the full UI,
which is mostly useful for docs builds so we can do a minimal compile
and still generate the docs.
* This allows a buidler to customise from e.g. /usr/lib/librenderdoc.so
to /usr/lib/renderdoc/librenderdoc.so - which is harmless since the
library is 'private' and not intended to be linked against directly.
* This really isn't ideal as it means the python module will only work
with that specific major.minor version of python, when it could in
theory work with any python version above 3.2 or so, depending on what
features are used.
* Since we're not distributing these modules yet though, add this
linking to support -Wl,--no-undefined.
baldurk