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
Attachment:
signature.asc
Description: This is a digitally signed message part