Fwd: Re: [Openal] alutLoadWAVFile

[Ryan C. Gordon]

> My question was more geared towards the problem that both AL/ALC and ALUT
> have been shipped as a *single* library on Linux. This is highly undesirable
> if ALUT is a more independent project with independent release cycles etc.,
> but on the other hand we might want to have some binary compatibility for
> already existing apps.

Oh, I see.

Seperate library sounds reasonable to me. GLUT and GLU do that as well, 
as befits a library developed outside the GL implementation anyhow.

To be clear, ALUT should be developed in the OpenAL CVS 
repository...someone mentioned making it a top-level project...this 
would keep it grouped closely with the rest of the project, but prevent 
it from depending on a given platform's implementation.

At least, I think that makes sense for now...we can always move it 
elsewhere later if it gets to be big.

> IMHO the best way to proceed here would be to make a clean cut and throw
> ALUT stuff out of libopenal.so and have a separate libalut.so. To ease the
> transition, binary releases for AL/ALC could include an additional
> "combined" libopenal.so, so desparate people could still use old apps using
> ALUT via libopenal.so through some LD_LIBRARY_PATH/symbolic link fiddling.

Just choosing new symbols for the new, improved ALUT and leaving the old 
ones to rot in libopenal seems clean enough for me...source and binary 
compatibility remains _and_ we can make a clean break. If we want to be 
forceful about it, make the old symbols print "DON'T USE THESE FUNCTIONS 
ANYMORE!" to stdout when called.  :)

--ryan.