[Openal-devel] AL headers
garinh at cheesetoast.net
Fri Sep 2 09:40:03 PDT 2005
> 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/
Here's the general response I've been getting from people over here
"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.
More information about the Openal-devel