[Mesa-dev] [PATCH] vulkan: Don't install vk_platform.h or vulkan.h.

[Chad Versace]

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>
> wrote:
> 
>     On 24 January 2017 at 18:02, Jason Ekstrand <jason at jlekstrand.net> wrote:
>     > On Tue, Jan 24, 2017 at 9:03 AM, Matt Turner <mattst88 at gmail.com> wrote:
>     >>
>     >> On Tue, Jan 24, 2017 at 8:41 AM, Emil Velikov <emil.l.velikov at gmail.com>
>     >> wrote:
>     >> > On 24 January 2017 at 00:54, Matt Turner <mattst88 at gmail.com> wrote:
>     >> >> These files belong to the vulkan loader.
>     >> > Fully agreed, patch is
>     >> > Reviewed-by: Emil Velikov <emil.velikov at collabora.com>
>     >>
>     >> Thanks!
>     >>
>     >> > Related question:
>     >> > I was wondering about getting this a step further:
>     >> >  - having the loader provide a .pc file
>     >> >  - tracking required version at configure time and dropping our local
>     >> > copies of the headers/xml.
>     >> >
>     >> > Would you be in favour, against, neutral of such an approach ?
>     >>
>     >> I'd be in favor of that, but let's see what Jason thinks.
>     >
>     >
>     > 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.

Matt's patch gets my
Reviewed-by: Chad Versace <chadversary at chromium.org>

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.