Newer versions of the XML and headers don't play nice. In particular the
VK_LAYER_EXPORT macro was removed and the XML was reworked quite
significantly, so our generator no longer works.
I was able to port newer version of the generator scripts from Mesa
(where these were copied from originally), although these new scripts
don't work with the old XML.
Just drop the meson knobs and always use the subproject version. In
practical terms this is identical to what Mesa also does... So Debian
DFSG should not be _too_ upset.
Closes: https://github.com/flightlessmango/MangoHud/issues/927
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Currently we have ld_libdir_abs which defaults to false. In that case,
both the mangohud shell wrapper, as well as the json files, reference
the DSOs directly without any path component.
This means that at run-time the dynamic linker, vulkan loader as well as
pressure-vessel will need to jump through hoops and figure out the
bitness of the DSO, whether one wants the 32 or 64bit one and even then
there will be confusing messages like:
fatal: /usr/lib/libMangoHud.so: wrong ELF class: ELFCLASS32
When set to true, as seen in the in-tree build.sh we'll append empty
path to LD_LIBRARY_PATH (bad), the full path with the $LIB token will be
used with LD_PRELOAD (good) and json files (bad).
Since we are generating separate json files, we can use the actual path
(while $LIB currently works, it's not really strict json nor documented
as supported). We can also drop the dubious LD_LIBRARY_PATH manipulation
This basically reinstates the prepend_libdir_vk=true option that was
dropped earlier.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
The option is always true for all distributions that build Mangohud.
While only the in-tree PKGBUILD disables it for undocumented reasons.
In practise the option will be enabled across the board - in different
manner, with latter commit. But for now, just remove it.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
The option defaults to false in-tree and across all distributions. The
only alleged use-case is the build.sh/build-srt.sh scripts. Although the
output of those scripts is absolutely identical with or w/o the flag.
Remove it.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Was introduced as a means to shorten the build cycles. With the static
lib helper it should no longer be needed.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
This option enables using system Vulkan headers when it doesn't share
the same datadir as MangoHud. This is specifically an issue in NixOS
where packages are built into their own isolated directories in
/nix/store.
For example:
/nix/store/9g28nz6zh484144mzw670bx82y1ka49a-vulkan-headers-1.2.162.0/share/vulkan/registry/vk.xml
This is currently worked around in the Nix package, by symlinking the
vulkan-headers into MangoHud's install directory:
5debc57760/pkgs/tools/graphics/mangohud/default.nix (L66-L70)
Although, this hack causes the vulkan-headers to be included as a
runtime dependency when they're only needed at build time.
I tried to figure out a way to resolve the datadir automatically, but
found that just adding a new option is probably the best solution for
the following reasons:
- The vulkan.pc file used to resolve dep_vulkan doesn't contain any
information about the datadir.
- The share directory could be resolved relative to the vulkan include
directory and that would solve the specific issue for Nix, but the
datadir could be installed anywhere and that wouldn't be a general
solution.
- I couldn't find a way to resolve the data dir using the XDG Base
Directory Specification because meson doesn't provide a way to access
the necessary environment variables.
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
