[Xorg] [Fwd: Re: CVS Update: xc (branch: trunk)]

[Eric Anholt]

On Mon, 2004-06-21 at 07:46, Keith Whitwell wrote:
> Alexander Gottwald wrote:
> > On Mon, 21 Jun 2004, Keith Whitwell wrote:
> > 
> > 
> >>I haven't looked at this change yet, but I'm leery of downstream modifications 
> >>to extras/Mesa/*.  If the change to GL/gl.h is warranted, it should be 
> >>submitted as a patch to Mesa.  This is a key file and changes to it are 
> >>closely monitored & must be well understood and justified.
> > 
> >  
> > 
> >>As it stands, I believe Mesa builds & runs on windows without modification.
> > 
> > 
> > This is not a change for win32 but for cygwin. Cygwin by default does not use
> > stdcall semantics but this is required if we wish to link to the windows opengl32 
> > library.
> > 
> > The patch only changes the GLAPIENTRY macro to use __stdcall if USE_OPENGL32 is 
> > defined. 
> > 
> > If it is required, I'll send it as a patch to mesa too.
> 
> That should be done by changing the definition of GLAPIENTRY - I haven't 
> looked at the change as I said, but it is 500+ lines of differences.

This is the effect of taking something off the vendor branch.  Instead
of getting the difference between the previous revision you would have
used (1.1.1.3) and the new revision (1.2), you get the diff listed
between the previous HEAD version (1.1) and the new revision 1.2.

Now, any time someone imports new Mesa, they'll have to manually merge
this file, and resolve conflicts in this file I think.  This is one
reason that taking things off the vendor branch that are updated from
the vendor is *strongly* discouraged.  I should have sent out a note
about this with the merge I did, but oh well.  Anyway, the best way to
deal with these things is to get the change into the vendor's tree, and
then either import it to our tree, or just import the fix itself on the
vendor branch knowing that it won't be wiped out with the next full
import.  If this fix gets merged to Mesa (such that no differences were
necessary between the vendor branch and HEAD), I think we can cvs admin
the file back onto the vendor branch and avoid any future merging mess
there.

Anyway, this is all what I understand.  I'll admit I'm still not fully
clued into vendor branch stuff, I've just listened to FreeBSD lists a
lot where a lot of attention is paid to this.

-- 
Eric Anholt                                eta at lclark.edu          
http://people.freebsd.org/~anholt/         anholt at FreeBSD.org