Re: Replace OpenAL with OpenAL Soft
First of all, I support switching to Soft since from one of first
posts it's obvious that SI breaks compatibility of a lot of software
on many architectures. If Soft can remedy that without additional work
of the other package authors, that alone is the reason to switch.
Regarding cmake issue: The whole point of the switch is to make it
transparent to everyone. Think glut->freeglut. You're not even aware
it's not real glut without reading docs!
On 4/26/08, Andres Mejia <mcitadel@gmail.com> wrote:
> 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
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-games-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
>
>
--
Ivan Vučica
-- Croatia --
Reply to: