[Mesa-dev] Directly using upstream headers (Was Re: [PATCH] vulkan: Don't install vk_platform.h or vulkan.h.)

[Emil Velikov]

On 25 January 2017 at 22:10, Chad Versace <chadversary at chromium.org> wrote:
> On Tue 24 Jan 2017, Jason Ekstrand wrote:
>> On Tue, Jan 24, 2017 at 11:25 AM, Emil Velikov <emil.l.velikov at gmail.com>

>>     > I'd rather not.  That would make sense if we all lived in the open-source
>>     > world where everything is upstream all the time.  Unfortunately, not all
>>     of
>>     > us have that luxury and we need to be able to work on experimental
>>     branches
>>     > of the spec that may have more extensions than are provided by any loader
>>     > version we can install.  I'd be ok with a check for a particular loader
>>     > version just to force distros to update their loader but I would like to
>>     be
>>     > able to build with arbitrary XML branches without having to install a
>>     branch
>>     > of the loader.
>>     What if I tell you that you wouldn't need to install the loader ;-)
>>     More as we get a .pc patches in.
>>
>>
>> A lot of extensions don't require explicit loader support.  I don't want to
>> have to update my loader (or put it in some folder and point pkg-config at it)
>> just to hack on them.
>
> And, Mesa should build Vulkan against its own imported headers.
> Otherwise, the Mesa build would effectively require version lock between
> it and the installed loader headers; this version lock is made more
> difficult because the loader headers aren't really versioned.  Upstream
> unintentionally breaks things. When I bisect Mesa with a git-bisect
> script, I do not also want to hack the script to checkout and re-install
> the loader during the bisect.
>
> Evidence: https://cgit.freedesktop.org/mesa/mesa/commit/?id=c085bfcec9915879e97a33c5235cf21607c72318
>
> A Bigger Problem: You cannot force the distro to upgrade its loader
> headers. If the loader-provided headers on Android N differ from those
> on Android O and Android P due to stupid upstream API breakage, and
> those once again differ from those in Fedora 25 and Fedora 29... Despite
> that, Mesa must continue to build on all supported platforms. Satisfying
> that may be hellish if Mesa builds against the system's Vulkan headers
> instead of its own.

In generally it's a matter of ensuring people do the better/more
robust (?) thing.
Sadly that means a bit (albeit somewhat trivial) amount of work on each side.

>From Vulkan (Mesa in general) developers, POV:
 - to point to the specific files

Distributions:
 - update regularly

Khronos:
 - ensure that both headers and XML files are updated for development
branches...
Having the script which generates vulkan.h/other publicly accessible
would be also nice ;-)
 - write tests and wire those to make check (or equivalent)

In practise neither one is easy due to the amount if people it needs
to be coordinated with. And considering that people are always busy
with more important thing... I don't see it happening soon :-(

Either way, I hope we don't get to a situation similar to the *GL* headers.
Emil