[Openal-devel] AL headers

[Garin Hiebert]

> FYI: I've just removed alctypes.h and altypes.h and merged them  
> into alc.h and al.h. I haven't heard any convincing argument for  
> their existence, and I've never header the need for a <GL/ 
> gltypes.h>...

Here's the general response I've been getting from people over here  
at Creative...

"WTF?  I've now got to merge new headers with my builds and re-test  
everything because some guy with CVS write access doesn't like a  
_cosmetic_ issue with the existing headers?"

This stuff has _impact_ on people's work.  Even though the change  
_should_ be a NOP, everyone now has to test to make sure that's the  
case.  The attitude on a change like this should not be, "Why _not_  
make this change?," it should be, "_Why_ make this change?".  It is  
_entirely_ a cosmetic issue, and should not have been changed.

> One additional thing: When AL(C)_NO_PROTOTYPES is defined, the  
> headers have variable *definitions* for the API entry points, not  
> *declarations*. This is ultra-evil (as already discussed before)  
> and I propose to remove those.

This setup has proven very useful, at least on Windows -- it allows  
someone to do their own runtime linking to OpenAL with next to no  
changes in their source code versus dynamic linking using the .lib  
file.  Don't make changes to anything related to this section unless  
you can get the agreement of Daniel Peacock and Carlo Vogelsang here  
at Creative (they both lurk on the list).

> What we should keep are the typedefs for the function pointers in  
> that case, although I'd prefer PFNALFOOPROC to LPALFOO to keep  
> consistency with GL headers (at least the Mesa ones). Any  
> objections to this? And alut.h should be similar in this respect,  
> too, of course...

In terms of Creative support -- if you can get agreement on a change  
from Dan and Carlo, that's fine.

Garin