* We search first in specified folders by the user (they can browse to
the android SDK and java JDK).
* If the tools we want aren't found there, we look relative to the UI
as we now distribute the required tools with windows builds.
* If we still don't find them, we prefer to look in PATH since the user
has 'opted in' to any tools found in there. If the tool isn't in PATH
either then we look relative to known environment variables.
* The directories are flattened since the #include paths aren't
relative and instead just #include "file.h". The recommended
solution is just to flatten the directory structure.
* Force loading librenderdoccmd.so in the Loader
* Build renderdoc as libVkLayer_GLES_RenderDoc.so, link renderdoccmd
against it, otherwise we will get UnsatisfiedLinkError when running
This removes dependencies on deprecated tools "ant" and "android project"
The new method relies on JAVA_HOME and ANDROID_SDK being set.
It also requires specific versions of the Android build-tools (26.0.1) and
platforms (android-23). See updates to CONTRIBUTING.md and our Travis-CI
config for details.
Travis-CI and documentation also roll forward to latest public NDK r14b.
This allows the library to be used as a Vulkan layer and shared
object for GLES debugging. It was already being renamed in the
distribution scripts. We've been renaming by hand for local
Vulkan development.
* Requires binary plugins to function from the RGA repository. These
will be included with distributions (nightly and stable builds) where
possible, however D3D disassembly currently requires the AMD driver
DLL which cannot be distributed. Placing it in the folder with the
other files will automatically work.
* 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.
* Thanks to build-master general @aras_p for the tip:
https://twitter.com/aras_p/status/841287101907910656
* The projects are still defined with the usual platforms Win32 and x64,
this only affects the naming in the solution configurations.
* Previously on VS2010, the DIA2 library wasn't properly supported on
64-bit, so it needed a separate program that always ran 32-bit and
proxied operations over a named pipe.
* Now DIA2 will load correctly in 32-bit and 64-bit, so we can do the
work in-process without needing the separate exe.
* We still need to distribute dbghelp.dll and symsrv.dll, so these now
live alongside renderdoc.dll in the build/install folder with matching
bitness.
* At the same time fixed a bug I noticed where the 0-based module index
would return 0 for the first valid module and be treated as invalid.