Fwd: Re: [Openal] alutLoadWAVFile
Ryan C. Gordon
icculus at clutteredmind.org
Mon Aug 22 04:41:49 PDT 2005
> 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. :)
More information about the Openal