[Mesa-dev] [PATCH] Remove GL_GLEXT_PROTOTYPES guards from non-ext headers.

[Emil Velikov]

On 13 September 2016 at 21:05, Eric Anholt <eric at anholt.net> wrote:
> Ilia Mirkin <imirkin at alum.mit.edu> writes:
>
>> On Mon, Sep 12, 2016 at 11:55 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>> On 12 September 2016 at 15:35, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>>> On Mon, Sep 12, 2016 at 10:10 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>>>> Keeping diff/patches in git always felt like a hack, imho. Plus
>>>>> most/all(?) distros rely on the Mesa headers, so I'm not sure how that
>>>>> is going to work.
>>>>
>>>> The alternatives are considerably more painful for just a handful of
>>>> files with a small number of diffs. This would be as a tool for
>>>> developers like us who update the mesa versions by importing new KHR
>>>> versions, which will not have our local changes applied. The patch
>>>> would not be used as part of the build process or anything else.
>>>>
>>> The goal being to have the patches alongside the patched headers.
>>> This way one can use them as reference ? Sure sounds great imho.
>>
>> Exactly. So that when I download new KHR headers, I just apply the
>> patch to them (and hope it applies), and if not, look at what was
>> being done and try to repeat the process. Then I regenerate the patch
>> against the (new) originals and check the whole thing in.
>
> Or you could just use git like normal: You have a public branch of the
> unchanged headers.  You make your own changes to the headers on master.
> When you want to update to new upstream headers, you check out the
> unchanged-headers branch, commit new unchanged upstreams there, check
> out master, and git merge.
I'd imagine that our (people/companies who are Khronos members) time
would be better spent on upstreaming things, rather than finding ways
how to manage the diff.

Or is it just me ?

-Emil