Re: new "in-compatible" alsa-lib PCM API

[Takashi Iwai <tiwai@suse.de>]

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 <perex@perex.cz> 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