[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Replace OpenAL with OpenAL Soft



On Friday 25 April 2008 5:58:11 am Yagisan wrote:
> On Wed, 2008-04-23 at 20:12 -0400, Andres Mejia wrote:
> > What I was thinking was to support the old libraries and the new
> > libraries at the same time, giving those who want to use one or the other
> > for their packages a choice. This of course is harder than it sounds.
> >
> > So yeah, renaming the current openal source package in the archive is a
> > good idea. It could be named openal-legacy. The binaries shipped by
> > openal however will need a change. One of the packages (preferably
> > openal-legacy) will have to rename the library to something else (like
> > openal0a), to avoid naming conflicts, especially with the development
> > packages. Also, the directory the header files are installed to will need
> > a different name
> > (like /usr/include/openal0a).
>
> Make sure you fix Modules/FindOpenAL.cmake in cmake to find the "legacy"
> openal files, and your new ones. I'd be annoyed as a user to find openal
> breaking because someone is changing the paths and not updating the
> build tools.

The openal-soft packages will be the new "openal" library, so cmake and any 
other build tools should not have any problem looking for and using these. 
They carry the same name (openal) and header files (AL/*). The openal-si 
packages however will be the "openalsi" library. The library name will be 
openalsi and the header files will be at "openalsi/AL/*".

It is still possible to manually search for and use any library using cmake 
and autotools (possibly jam too). A change to the build tools would be nice, 
but I think it will be far easier for a package maintainer to manually change 
their configure.ac, CMakeLists.txt, or whatever other file necessary to find 
the "openalsi" libraries instead of the "openal" libraries. Of course, no 
changes will be needed if they use the openal-soft packages instead.

-- 
Regards,
Andres


Reply to: