[Mesa-dev] [PATCH 7/7] glx: unify GLX_SGIX_pbuffer aliased declarations

[Emil Velikov]

On 6 December 2016 at 18:08, Jeremy Huddleston Sequoia
<jeremyhu at apple.com> wrote:
>
>> On Dec 6, 2016, at 06:04, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>
>> On 5 December 2016 at 22:50, Jeremy Huddleston Sequoia
>> <jeremyhu at apple.com> wrote:
>>>
>>>> On Dec 5, 2016, at 11:52 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>>>
>>>> From: Emil Velikov <emil.velikov at collabora.com>
>>>>
>>>> No point in having an identical code in two places.
>>>>
>>>> Not to mention that the Apple one incorrectly uses GLXDrawable as pbuf
>>>> type. This change is both API and ABI safe since the header uses the
>>>> correct GLXPbufferSGIX and both types are a typedef of the same
>>>> primitive XID.
>>>>
>>>> Cc: Jeremy Huddleston Sequoia <jeremyhu at apple.com>
>>>> Signed-off-by: Emil Velikov <emil.velikov at collabora.com>
>>>
>>> Reviewed-by: Jeremy Sequoia <jeremyhu at apple.com>
>>> (not tested yet, though)
>>>
>> Thanks.
>>
>>>> ---
>>>> Jeremy, humble poke to send any/all Macports patches to the list ;-)
>>>
>>> What patches are you referring to?  AFAIK, all the patches we have in MacPorts are hacks that have been rejected by mesa or are things I don't think should be in mesa due to lack of polish/hack status.  See:
>>>    https://github.com/macports/macports-ports/tree/master/x11/mesa/files
>>>
>> Almost, but not quite ;-)
>>
>> - 0001-mesa-Deal-with-size-differences-between-GLuint-and-G.patch
>> Should not longer be needed with the BUILDING_MESA workaround.
>
> Thanks, I'll give that a try.
>
>> - 0002-applegl-Provide-requirements-of-_SET_DrawBuffers.patch
>> Some serious work needed.
>
> Yep.  That's why I haven't resent it.  Need time to make it better.
>
>> - 0003-glext.h-Add-missing-include-of-stddef.h-for-ptrdiff_.patch
>> Should not be needed since the header is included further up in the
>> file. Alternatively poke Khronos and upstream it.
>
> Yep, that was the result of the conversation on the list.  I filed a khronos bug and don't think they've acted on it.  I'll check the status when I get some time.
>
The only way I see this being an issue is by something (glcorearb.h ?)
is setting the GL_VERSION_1_5 define before including glext.h, thus
the #include <stddef.h> [in the #ifndef GL_VERSION_1_5 section] gets
omitted.

Then again we should get all the includes at the top or at least
outside the "extern C" guard. I'll see if we can get these sorted.

>> - no-missing-prototypes-error.patch
>> No traces of it on the list and no commit message describing why it's
>> needed :'-(
>
> https://trac.macports.org/ticket/46827
>
> IMO, this is a hack and doesn't meet the bar of upstreaming at this quality level as it's not a real fix.
>
Hmm nasty indeed. Fwiw it looks like a nice candidate to address in
the toolchain.

>> - patch-include-GL-mesa_glinterop_h.diff
>> No longer needed - fixed upstream
>
> Thanks.  I'll test removing it when I get a chance.
>
>> - static-strndup.patch
>> We have WIN32(?) strndup in src/util/strndup.[ch]. Static inline into
>> include/posix_string.h alongside strnlen. Or better yet add a patch
>> for the build toolchain, thus one doesn't need to fix these in every
>> project ;-)
>
> Yeah, that's why I haven't upstreamed this.  It's not the correct fix.
>
> The build toolchain can't be patched.  It is the gcc-4.2 that shipped with Xcode 3 about 10 years ago.  We try to support the Apple-provided toolchain for building ports for as long as possible.  When it becomes too unwieldy, we blacklist it in individual ports.  That causes a newer toolchain to be used (my preferred ones being clang-3.4 or clang-3.7; clang-3.8 has some bad codegen issues, so I don't trust it, and 3.9+ currently don't build on Snow Leopard).
>
Thinking out loud (sort of):

If permissions to the header(s) is not an issue one can add static
inline implementations (and missing declarations ?). Alternatively
having a "cc" wrapper which always includes the local (fixed)
header(s) prior to anything else should get you going.
At the same time: not sure how many other projects depend on such
fixes, so it may be that doing this will be more work than what its
worth.

Thanks
Emil