At Wed, 18 Sep 2002 14:21:44 +0200 (CEST), Jaroslav Kysela wrote: > > On Wed, 18 Sep 2002, [iso-8859-1] Chris Rankin wrote: > > > --- Jaroslav Kysela <[EMAIL PROTECTED]> wrote: > On Wed, > > 18 Sep 2002, Chris Rankin wrote: > > > Note: If > > > SND_COMPATIBILITY_BUILD_RC3 is defined, > > > then applications need to fall back to 0.9.0rc3 API > > > as well. > > > > So maybe we could have a --with-compat-rc3 option for > > alsa-utils as well? Regardless of which alsa-lib I > > build, I always need to be able to build alsa-utils. > > And I doubt that wine and xine will get updated before > > -rc4 is released. (Unless there's a document somewhere > > explaining the relationship between the old and new > > API functions, in which case I could submit patches > > myself.) > > It seems, that you're not understand the compatibility. > > 1) build library with --with-compat-rc3 and place it to some > other directory > 3) build library without --with-compat-rc3, place it to > /usr/lib as usuall > 4) build alsa-utils and newer applications > 5) build older applications with compatible library compiled > with --with-compat-rc3 > > Old and new software will co-exist without any problems. Perhaps, we > can have some good default place for rc3 compatible library and add an > autoconfiguration code to alsa.m4. My suggestion is to use /opt/alsa/rc3 > directory for this job. Comments?
well, i think this is too complicated. if we need two lib binaries, then let's use different so numbers, not the different paths. i.e. compat-rc3 --> build libasound.so.2 without versioned symbols. new lib --> build libasound.so.3 with versioned symbols for the future confliction. and how about to separate the function declarations of these two versions into individual parts (or files) instead of combined declarations with a macro (or ifdef)? the old functions will be never changed in future. ... but still i'd prefer adding new functions (or changing the whole snd_pcm_hw_params_xxx to different names such like snd_pcm_hw_setup_xxx to avoid confliction) to modifying the existing api functions. so there will be no compatibility problem at this time. ciao, Takashi ------------------------------------------------------- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel