Re: [Freeglut-developer] contributions and status

[Brian P. <br...@tu...>]

Steve Baker wrote:
> Fay John F Contr AAC/WMG wrote:
> 
>>         (1) Everybody gets his changes into CVS
>>         (2) Everybody checks out the new CVS version and runs all his 
>> pet programs using it
>>         (3) Somebody creates a release tarball
> 
> 
> A "release candidate" to use the trendy jargon.
> 
>>         (4) Everybody checks out the release tarball and makes sure it 
>> runs properly on his system
>>         (5) Steve Baker announces a new release.
> 
> 
> Hmmm - I feel that a fanfare should be item 4.5  :-)
> 
>> While I have been in open source projects for a while, I have never 
>> overseen this sort of thing before.  I am certainly open to hints, 
>> suggestions, or even an outright transfer of control to somebody 
>> else.  I just don't want to see the ball dropped.
> 
> 
> How do you feel about sticking in the glutGetProcAddress thing?
> 
> It really just needs to be a wrapper around glXGetProcAddress and 
> wglGetProcAddress,
> with a test to see if the first four letters of the string are "glut" - 
> and a
> hash-lookup into a table of all of the freeglut functions.

I didn't bother with a hash table.  It's just a loop over an array of 
all the GLUT function names.  glutGetProcAddress() doesn't have to be 
high-performance.


> The semantics are ever so slightly messy because glXGetProcAddress
> returns a result that's specific to the current rendering context and
> wglGetProcAddress returns the same result for all rendering contexts.

Actually, it's just the opposite way; GLX's pointers are context 
independent.


> We can solve that by simply saying that freeglut works the X way, so
> you have to call it in each rendering context...this will be a little
> redundant in Windows - but it'll at least be consistent.

We'll say it works the WGL way; call glutGetProcAddress for each 
window/context to be safe.

-Brian