Re: Replace OpenAL with OpenAL Soft
On Friday 25 April 2008 10:41:28 pm Yagisan wrote:
> On Fri, 2008-04-25 at 13:43 -0400, Andres Mejia wrote:
> > 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/*".
>
> Yes - that is the point. You will be moving the directory, breaking the
> FindOpenAL module of cmake and every single application that is built
> with cmake that uses it. Sure it would probably still work with the
> "new" library, but it will not with the "si" package.
>
> > It is still possible to manually search for and use any library using
> > cmake and autotools (possibly jam too).
>
> I'm not familiar with the other build tools - they were unsuitable for
> my use case. I am familiar with cmake having used it for several
> projects now.
>
> > 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.
>
> If I am using openalsi and suddenly my programs fail to link because the
> package maintainer has changed the the paths to not match upstream, and
> not updated the new paths *and* library names in the cmake
> Find<packagename>, I as a user will be very grumpy and file rc level
> bugs demanding a fix for the regression.
>
> I as a user am not wiling to write my own cross platform
> Find<packagename> cmake module for a standard distribution supplied
> package. That is the entire reason I use Find<packagename> instead of
> writing my own.
>
> > Of course, no
> > changes will be needed if they use the openal-soft packages instead.
>
> Indeed.
>
> Regards,
> Yagisan
OpenAL Soft is meant as a direct update/replacement to the OpenAL SI library.
One or the other must carry the library name "openal" and the include path
of "AL/*" for their headers. Since the OpenAL SI library has gone
unmaintained for a long time now and OpenAL Soft is a more active project, it
makes much more sense to rely on the OpenAL Soft library as the
default "openal" library for all projects using it.
I've counted 30 packages depending or build-depending on the "openal" library.
It's still too early to see if it's even worthwhile to change the build tools
to use the "openalsi" library, let alone if we should even distribute them.
The OpenAL Soft library hasn't even been uploaded to the archive yet. We
don't know the number of packages that build and/or run on the new "openal"
or the number of packages that fail to build and/or run.
--
Regards,
Andres
Reply to: