* 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.
* This is primarily useful for HLSL on Vulkan, but could be used with any other
combination. If multiple tools can perform the conversion, the highest
priority one is used.
* On GL addressing modes are called wrap modes, and the wrap value is then known
as repeat. If we don't 'localise' this then it can be confusing to show that
it is "Wrap".
* rdcstr no longer inherits from rdcarray, it implements all functionality
itself.
* There are now three representations:
- Heap-allocated, same as how rdcarray behaves.
- Local-allocated, for small strings we store them in a union array.
- Compile-time literal, only created from user-defined literals.
* The main observation is that a lot of RenderDoc's strings are compile-time
literals either from struct names, member names, or stringified enum values.
Storing these directly and allowing them to be moved and copied quickly saves
on allocations and time. When the string is modified, it's copied to one of the other formats.
* Typeless textures must be interpreted as some kind of format, so without a
better hint we use UNORM as a default. Ensure that this is listed explicitly
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
baldurk