[PATCH xserver] configure.ac: bump epoxy requirement to 1.2

[Emil Velikov]

On 25 October 2016 at 15:59, Adam Jackson <ajax at redhat.com> wrote:
> On Mon, 2016-10-24 at 12:19 -0700, Matt Turner wrote:
>> On Mon, Oct 24, 2016 at 2:39 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> > > > From: Emil Velikov <emil.velikov at collabora.com>
>> >
>> > As pointed out in the ABI tracker[1], epoxy has gone through a few
>> > non-backwards compatible ABI changes, yet preserved the DSO name.
>
> I don't particularly object to bumping the required version, but...
>
>> > Most noticeable of which, from xserver POV, in epoxy_has_egl_extension()
>> > - s/EGLDisplay */EGLDisplay/.
>
> This happens not to matter. If you read the corresponding commit you'll
> see that the parameter was always treated as an opaque pointer anyway:
>
> https://github.com/anholt/libepoxy/commit/e20b3ce6c7895f355fd1bad81b45341d98b5ee76
>
Maybe coffee hasn't kicked in, but it does seem to matter.

Think about: build against pre 1.2 [epoxy] then run against 1.2 or
later and you'll get some lovely fireworks.

>> > Eric, iirc Dave had some ideas about moving libepoxy to fd.o [+ making
>> > it the canonical/upstream source] and was looking for your blessing.
>> >
>> > How is that going ? The state of the github repo looks tragic.
>>
>> ajax and anholt were talking about epoxy's status at XDC. Cc'ing ajax.
>
> I'm honestly on anholt's side here about leaving upstream on github.
> fdo is lovely and all but the contribution model for people not already
> in posession of an fdo account is terrible. Moving epoxy to fdo would
> be a step backwards, and we should continue to hold out on that front
> until fdo grows better collaborative hosting.
>
> The more serious issue to me is that epoxy needs a release, and that
> release should involve merging up the various forks on github. (This is
> an argument _in favor_ of github: not only was it easy for people to
> create their forks, but we can track them all down easily.) I'm sure
> epoxy isn't Eric's first priority (which is entirely reasonable) so
> it's kind of up to him how to proceed here.
>
Seems like we've dived into [the] unintended direction. The goal is to
see how things start rolling again - would that be fd.o github,
whatever.

Nitpicking pros/cons for each one is a very subjective and never
ending battle that I'd rather not take part of :-)

Thanks
Emil