We got some build failures with DXVK-NVAPI due to this. They even have
CI that uses Proton SDK images but since we create our own cross files
they were not anticipating that we may be forcing a C++ standard
version.
Since everything builds and none of the meson-using subprojects seems to
be setting the version via their provided corss files we should be good
to just drop it.
That path can be relative when the build directory is inside the Proton
source directory. Since it then used to patch compile_commands.json, it
is important that it is absolute, otherwise it implicitly becomes grafted
to a directory for which it is meaningless.
Since we moved the rsync into the container, configure dependency on
configure.ac was broken, leading to it not being regenerated until a
second build. This is because timestamps are read by make earlier than
the rsync, which runs after the top-level rules are checked.
All compile_commands.json from the build directories will be copied to
the compile_commands subdirectory adjusting the paths of the source to
point to the real (not the rsynced) one.
NOTE: it still may point to the build dir for things like generated config.h
Due to how we handle building and compilation flags we end up with a lot
of warnings that are normally hidden. Let's introudce an option to
suppress them for CI builds to generate smaller, more searchable logs.
Parts of the rules, including the magical ones created via
make/rules-*.mk, are executed inside of the container via SHELL
override, and parts are executed on the host side.
This makes reasoning about and debugging the rules much harder than it
should be. It also requirs the users to have certain programs installed
on the host in addition to docker/podman.
With this change `make` will act as a simple pass through to inside of
the container for the most part.
One notable exception is installation which still happens the host side.
The second grep in sequence can exit early (-q, as soon as we have one
match it exits with a success) which makes the first grep unhappy as its
write pipe is closed early, resulting in:
syncing vulkan-loader... grep: write error: Broken pipe
Let's silence those errors.
This fixes steam.exe.so not being able to start from system32
automatically, as the fake module was flagged with IMAGE_FILE_DLL, which
caused GetBinaryTypeW to fail.