* Unfortunately the new upcoming debian has made the really poor decision to
actively *delete* the pcre package, breaking any programs depending on it even
at build time. As far as I can see it's still available in most other common
distributions.
* Users could easily build it themselves but would have to install it system
wide for it to be picked up. This kind of dependency absolutely should not be
something the build system has to set up itself but when distributions make
poor choices we have little choice but to adapt somehow.
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
Xcode does not match the cmake behaviour of rerunning the target every time if the output file does not exist and then letting the Qt build system handle dependency checking.
Xcode has a property to behave like this, however that is not exposed by cmake.
To improve this for the Xcode qrenderdoc project manually add qrenderdoc sources files as dependencies.
Changed the Xcode project for qrenderdoc to add the files to the UI grouped by the file system folders using the cmake source_group(TREE *) command.
Hardcoded to Code, Styles, Widgets, Windows *.h*, *.c*, *.m*
These files are not built by Xcode.
They are in the Xcode project to support browsing qrenderdoc source code.
Capture the PATH variable at cmake invoke time and store in the cache.
Use the captured PATH variable for the make based build targets custom_swig and QRenderDoc.
This fixes the problem on Apple Silicon that the Xcode PATH does not include the default homebrew paths (/opt/homebrew/bin /opt/homebrew/sbin)
Restrict the schemes to match the configuration on the cmake command line
Disable Debug Document Versioning
Specify the executable path for build-qrenderdoc target
The python brew install does not include universal binaries
Disabling pyrenderdoc on Apple allows for the generation of universal binaries by the Apple CI
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
* By default cmake will print huge scary warnings if the packages aren't
available instead of silently continuing and letting us check, which is a bad
default for optional packages.
* We also reverse Python_ADDITIONAL_VERSIONS so it finds the newest one. It
doesn't seem like there's a way in general to make these match, so we hope
that searching from newest to oldest will find the same in both - or at least
it makes it easier for the user to fix by installing the newest in both.
* It seems like packaging of these two is inconsistent, and pyside2 dev files
being available doesn't always imply shiboken2 dev files are present. Be safe
and check both.
This is an alternative to
https://github.com/baldurk/renderdoc/pull/1768 suggested by baldurk.
I found that for some reason when cross compiling, the qrenderdoc
CMakeLists.txt was failing to see the include-bin executable that
renderdoc should have built.
Apparently the .py.c files were no longer required for qrenderdoc, so
removing it also fixed the issue I was seeing.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
* This is only lightly tested and may break heavily. It is disabled by default
and must be explicitly enabled.
* In particular this is only known to work for Wayland use at capture time.
Wayland on replay is still unsupported. Known issues include: EGL pbuffer
surfaces are not implemented on Wayland, Wayland cannot get window dimensions,
and there are hangs/failures with GL and vulkan presentation with Wayland.
* 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
baldurk