* This seemed to cause crashes on some systems as libproxy links to libstdc++
and can then cause symbol conflicts between the static libstdc++ and the
system's libstdc++.
* libproxy itself cannot be statically linked, so the solution is either to
configure Qt without libproxy and break anyone who needs proxy support, or
stop statically linking libstdc++ and add a new dependency. At commit time
most distributions have at least g++-5's libstdc++ in their minspec so we can
require that - the main two that seem to fall short are Debian Jessie and
CentOS 7. Users on those systems will have to install a newer libstdc++ or
compile from source rather than using the binary releases.
* We also only use GIT_COMMIT_HASH where necessary to avoid rebuilding many
files for no reason, including splitting version.cpp out into a separate
project as we do with VS since otherwise changing its preprocessor defines
rebuilds the whole renderdoc project.
* At the same time, move the git hash to be internal only so we don't have to
try to link version.cpp into other projects like renderdoccmd or qrenderdoc.
When QtCreator is used to build a CMake script, it defaults to storing
the qmake to use in the variable "QT_QMAKE_EXECUTABLE"
(this is tweakable in Tools->Options->Kits->CMake generator)
We detect if QT_QMAKE_EXECUTABLE is already defined and if so, use that
setting. Otherwise use the previous default (which is "qmake")
Why this change? A user may have several Qt versions installed, and
QtCreator supports managing between them via the IDE.
Without this change the user will change between kits in the IDE but
Renderdoc will still use the default qmake.
This is problematic in Linux systems because the Qt version installed
via the Qt installer is often more up to date than the distro-provided
one
* This invokes run_tests.py with any arguments but specifies the renderdoc
module and python module paths automatically. Only works if built within the
project repo itself as otherwise it won't locate the test script
On Apple only set CMAKE_LIBRARY_OUTPUT_DIRECTORY to be “lib” folder instead of “bin” folder
Fixes osx problem when launching renderdoccmd not being able to find librenderdoc.dylib
RPATH is set to be "@executable_path/../lib" which matches where qrenderdoc.app copies the renderdoc library to
qrenderdoc: set library search folder “-L” to be CMAKE_LIBRARY_OUTPUT_DIRECTORY instead of CMAKE_RUNTIME_OUTPUT_DIRECTORY
* Normally we want to inherit CC and CXX from the parent process to ensure that
the user's choice of compiler is respected. Unfortunately macOS 10.14 starts
shipping broken compilers, so inheriting CC & CXX causes the swig compilation
to fail.
* As a workaround, we just disable this on macOS assuming the user won't ever
want to override CC & CXX because it's all locked into XCode anyway.
* It's already optional on linux due to distributions not necessarily
carrying packages for it yet. We also make it optional on windows
since by the same measure it's not a huge problem if it's missing, and
official builds will include it. This means we don't have to ship the
binary dependencies
* 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.
* Enums are now proper python enums instead of just being a class with
static int members.
* Fix a refcounting issue with SWIG generated code to access nested
child structs.
* 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 avoids rebuilding swig every time if some internal cpp in the
renderdoc target changes, but will still rebuild it if the interface
headers change.
* Tacking -official onto the git hash was a hack only needed on windows,
and since we want more information it doesn't scale.
* Instead we track anything we need to know about the version in
separate variables, like whether it's a stable build or a nightly/
local build. Or if it's built by a downstream distribution then the
version number for the downstream build.
* This is only relevant for static qrenderdoc builds where the python
used isn't the system python, so it needs to locate its libs.
Otherwise the system libpython3.so and libs will be used.
* SWIG outputs two files - renderdoc_python.cpp with the main actual
wrapping code, and renderdoc.py a small module that does some
bootstrapping on python side.
* We use a custom version of SWIG that generates strong/typed enums in
python based on enum classes, so in cmake we add this custom swig
fork as an external project and compile it before generating the
wrappers. On windows there's a committed version of the SWIG binary
that gets run directly from the .pro or .vcxproj.
* The renderdoc.py gets embedded as a resource on windows or as a C
generated unsigned char array via include-bin on other platforms, so
that we can insert it into the python context without needing it to
sit around on disk somewhere in sys.path
* Previously the cmake build would put librenderdoc.so in a /bin folder
in the source folder so the qt creator project could link against a
fixed path when just opening the project solo.
* This won't scale though for fetching the SWIG outputs from cmake, and
it's ugly to modify the source folder for out-of-source builds.
* Instead we have cmake generate a qt creator include file with all of
the settings and paths needed, and pass the CMAKE_BINARY_DIR into
qmake when building. This does mean that when opening the project in
qt creator you need to specify CMAKE_DIR=/path/to/build though.
* As a bonus, this means we can let cmake identify where python is and
have qt creator link against it rather than having to hardcode include
paths etc.
* When cmake custom commands invoke make, the make execution is silent.
The MAKEFLAGS reset was to remove the silent flag, but it also lost
the -j parallel build flags.
* Instead, we set qmake to silent mode (which it already was going to
be), and that causes it to add echo statements to each rule that will
be printed even when make is silent.
baldurk