[Mesa-dev] [PATCH] [rfc] dri3: allow building against older xcb

[Emil Velikov]

On 12 March 2018 at 18:48, Dave Airlie <airlied at gmail.com> wrote:
> On 13 March 2018 at 03:24, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> Hi Dave,
>>
>> On 11 March 2018 at 23:26, Dave Airlie <airlied at gmail.com> wrote:
>>> From: Dave Airlie <airlied at redhat.com>
>>>
>>> I'm not sure everyone wants to be updating their dri3 in a forced
>>> march setting, this allows a nicer approach, esp when you want
>>> to build on distro that aren't brand new.
>>>
>>> I'm sure there are plenty of ways this patch could be cleaner,
>>> and I've also not built it against an updated dri3.
>>
>> Have you considered cases where the build server is using 1.12, while
>> at run-time we have 1.13?
>> Are you explicitly forbidding that, say via the packaging? It tends to
>> be allowed on most(all?) distributions.
>
> Yes I am because really who does that, and why do I care.
>
Sounds like I stepped on your toes here. Pardon, did not mean to.

All I've seen is distribution packaging ensuring the runtime version
is at least equal to the build-time one.
I have not seen the opposite, hence the question.

> If you build against a newer libxcb it won't run against the older one either,
> why do you expect building against the older one will magically work against
> a newer one with all the features?
>
Very often an updated version is of dependency is shipped, yet the
package (say mesa) is not rebuilt.
AFAICT there's no clear way to annotate this kind of 'hidden'
dependency, thus package maintainers don't know about it.

Hence, causing fair amount of time lost in user frustration and
developers debugging.

>> That said, if updating XCB is a serious no-go, may I suggest something
>> like the following:
>>  - add local fallback definitions/declarations
>>  - add local functions (annotated as weak) which return 'the correct'
>> value so that the fallback paths kick in
>
> I can sorta see the first part being useful, the second is definitely
> over engineering
> the solution.
>
> The thing is most of the features in dri3.1 are gated on the X server
> having support,
> Most people are not updating their X servers, I'm guessing apart from
> the modifiers
> devs there'll be at most 10 people who update their X server for this
> feature in advance
> of a distro moving them to it. I know I won't personally be going
> around all 10 boxes I
> keep running updating their X server for a feature that doesn't add
> anything on those
> hw configurations yet. When distros move to the 1.20 X server they'll
> also move to newer
> xcb, this is for distros that won't move at all.
>
Hey, I'm just sharing an idea of what sounds like the more robust
solution. It should work "for everyone" even though it seem like an
overkill.
I dare not think of the xcb/xserver/mesa combinations that people use.

As long as people are on board with the fun experience mentioned
above, don't mind me ;-)

HTH
Emil