On Fri, 20 Sep 2002, Kai Vehmanen wrote:
> On Fri, 20 Sep 2002, Takashi Iwai wrote:
>
> >>your almost all negative messages persuaded me to wait awhile with
> >> new function prototypes. Here is the result:
> > thanks for quick reaction.
> > the new library works fine with the old applicati
On Fri, 20 Sep 2002, Takashi Iwai wrote:
>> your almost all negative messages persuaded me to wait awhile with
>> new function prototypes. Here is the result:
> thanks for quick reaction.
> the new library works fine with the old applications.
Btw; with ld from binutils-2.9.5.0.22-6 (rh62)
Hi Jaroslav,
At Thu, 19 Sep 2002 17:29:48 +0200 (CEST),
Jaroslav Kysela wrote:
>
> Hi all,
>
> your almost all negative messages persuaded me to wait awhile with
> new function prototypes. Here is the result:
thanks for quick reaction.
the new library works fine with the old application
Jaroslav Kysela <[EMAIL PROTECTED]> writes:
> your almost all negative messages persuaded me to wait awhile with
> new function prototypes.
Thanks for listening, Jaroslav. :-)
I intended my comments to be "negative" only in the narrow sense
("let's don't do this"), and not in the broad
Hi all,
your almost all negative messages persuaded me to wait awhile with
new function prototypes. Here is the result:
- .so library number returned to .2
- library builds with versioned symbols since now, default tag is ALSA_0.9
- new snd_pcm_hw_params_* function are available with ta
--- Chris Rankin <[EMAIL PROTECTED]> wrote: > ---
Jaroslav Kysela <[EMAIL PROTECTED]> wrote: > On
> The possible solutions from my perspective are:
> - I install BOTH libraries, each with full headers
> (somehow)
Oh yes, and the compatibility version has to go in
/usr because that's where the r
--- Jaroslav Kysela <[EMAIL PROTECTED]> wrote: > On Wed,
18 Sep 2002, [iso-8859-1] Chris Rankin
> wrote:
>> It seems, that you're not understand the
> compatibility.
That's possible - or maybe the existing
"compatibility" is woefully inadequate for the scale
of the problem?
The applications tha
> > > 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 al
On Wed, Sep 18, 2002 at 06:51:11PM +0200, Takashi Iwai wrote:
> one related question is -
> is there any problem to keep alsa.m4 file? or should it be removed
> and force people to move to pkg-config from AC macros?
Removing alsa.m4 is probably the best way to speed up adoption of
pkg-config b
At Wed, 18 Sep 2002 09:49:55 -0400,
Paul Davis wrote:
>
> at the very least, move to pkgconfig so that apps can find the alsa
> libs easily.
i put alsa.pc in alsa-lib. please check whether it's ok.
one related question is -
is there any problem to keep alsa.m4 file? or should it be removed
a
Jaroslav,
I must respectfully point out that your response proves that there
*is* a problem. This solution is *compicated*. You're a smart guy.
You probably feel you understand all its implications. Perhaps you
do. But, most ALSA users and developers *do not* and *will not*.
I am sorry to re
On Wednesday 18 September 2002 16:18, Paul Davis wrote:
> its part of all distributions at this point. its about as standard as
> autoconf.
While it may be part of the distros it's not always installed as default.
My SuSE 8.0 DVD has it on but I still had to fish it out.
While we're at it - did
Tim Goetze wrote:
> now that i think about it some more, i feel compelled to add:
>
> this dance around the 0.9.0 version seems ridiculous to me. the
> logical consequence of API changes is bumping the version number,
> and not hiding it in a 'nano' version increment.
>
> sorry for the harsh wo
>> anyway, i agree with paul that pkg-config should be used instead,
>> which offers a lot more flexibility.
>
>That's as maybe but it's "non-standard" still isn't it? Another dependency
>in a complicated world. I think it's too soon.
its part of all distributions at this point. its about as st
At Wed, 18 Sep 2002 10:19:48 -0400,
Paul Davis wrote:
>
> this causes no end of difficulties when using software that is
> generally installed from a tgz or CVS (such as ALSA) on systems where
> autoconf was installed from a package. autoconf will complain that it
> can't find the foo.m4 file (be
On Wednesday 18 September 2002 15:50, Tim Goetze wrote:
> anyway, i agree with paul that pkg-config should be used instead,
> which offers a lot more flexibility.
That's as maybe but it's "non-standard" still isn't it? Another dependency
in a complicated world. I think it's too soon.
However,
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,
> > > the
Thierry Vignaud wrote:
>Tim Goetze <[EMAIL PROTECTED]> writes:
>
>> > autoconfiguration code to alsa.m4. My suggestion is to use
>> > /opt/alsa/rc3 directory for this job. Comments?
>>
>> /opt is redhat only, debian systems do not have it.
>
>err, even if i dislike it, /opt is defined by the fhs
On Tue, 17 Sep 2002, Jaroslav Kysela wrote:
> After some thoughs, I think that this sort of cleanups is good for
> implementing at any time. It doesn't break the implementation (in the
> sense of behaviour), but it makes that older code is not compilable.
> Fortunately, any C programmer
>this is the /usr/share/aclocal/alsa.m4 job to provide right linking
>flags depending of the library
ah. typical autoconf confusion here.
autoconf looks in only ONE directory by default for *.m4 files. if it
was installed from a package, it probably looks in
/usr/share/aclocal. if it was install
Tim Goetze <[EMAIL PROTECTED]> writes:
> > autoconfiguration code to alsa.m4. My suggestion is to use
> > /opt/alsa/rc3 directory for this job. Comments?
>
> /opt is redhat only, debian systems do not have it.
err, even if i dislike it, /opt is defined by the fhs
anyway, api incompatibles libra
>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
>
>
Jaroslav Kysela wrote:
>autoconfiguration code to alsa.m4. My suggestion is to use /opt/alsa/rc3
>directory for this job. Comments?
/opt is redhat only, debian systems do not have it.
tim
---
This SF.NET email is sponsored by: AMD - Your a
On Wed, Sep 18, 2002 at 01:02:35PM +0100, Chris Rankin wrote:
> So maybe we could have a --with-compat-rc3 option for
> alsa-utils as well?
I don't think there has been any other changes. Just use rc3 alsa-utils.
> And I doubt that wine and xine will get updated before
> -rc4 is released.
> (Un
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 coul
--- 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
On Wednesday 18 September 2002 11:06, Takashi Iwai wrote:
> > Wake me up when it's all over.
>
> please give comments before going to bed.
> (otherwise you will lose the right to whinge ;)
> the decision should not be done self-righteously.
I know that you and Jaroslav will come to a fair an equi
At Wed, 18 Sep 2002 10:46:42 +0100,
Richard Bown wrote:
>
> On Wednesday 18 September 2002 10:36, Takashi Iwai wrote:
>
> > using the versioned symbols is a good idea. it should go into
> > libasound.so.3 to avoid the further confliction.
>
> I don't know about anyone else but I'm really confu
On Wednesday 18 September 2002 10:36, Takashi Iwai wrote:
> using the versioned symbols is a good idea. it should go into
> libasound.so.3 to avoid the further confliction.
I don't know about anyone else but I'm really confused.
All I know is that JACK CVS doesn't build out of the box with ALS
At Tue, 17 Sep 2002 14:58:42 +0200 (CEST),
Jaroslav Kysela wrote:
>
> Hi all,
>
> I've made a simple cleanup which unifies all snd_pcm_hw_params_*
> functions. The first set of changes are in CVS a few days, but some
> developers pointed that the backwards compatibility is a right thing.
On 17 Sep 2002, Jack O'Quin wrote:
> Is this a "Release-Critical" bug fix?
>
> If not, I think source- and binary-incompatible changes are highly
> inappropriate right now. A "release candidate" is supposed to
> *stabilize* the interface and implementation. Making an incompatible
> change be
On Wed, 18 Sep 2002, Chris Rankin wrote:
> Does this mean that the alsa-lib needs to be updated in CVS to be -rc4?
> I am trying to compile xine and wine from CVS as well as ALSA, and this
> doesn't work because alsa-utils needs the new headers but xine and wine
> currently need the old ones.
Is this a "Release-Critical" bug fix?
If not, I think source- and binary-incompatible changes are highly
inappropriate right now. A "release candidate" is supposed to
*stabilize* the interface and implementation. Making an incompatible
change between rc3 and rc4 looks like a big step backwar
Does this mean that the alsa-lib needs to be updated in CVS to be -rc4?
I am trying to compile xine and wine from CVS as well as ALSA, and this
doesn't work because alsa-utils needs the new headers but xine and wine
currently need the old ones. I imagine that the xine and wine people can
updat
On Tue, 17 Sep 2002, Kai Vehmanen wrote:
> On Tue, 17 Sep 2002, Jaroslav Kysela wrote:
>
> > 1) New "versioned" library is libasound.so.3, so that older applications
> >uses older libasound.so.2.
>
> Hmm, the 'Versions' ld script doesn't seem to be in CVS, and as a result,
> linking alsa-
On Tue, 17 Sep 2002, Jaroslav Kysela wrote:
> 1) New "versioned" library is libasound.so.3, so that older applications
>uses older libasound.so.2.
Hmm, the 'Versions' ld script doesn't seem to be in CVS, and as a result,
linking alsa-lib currently fails. Have I missed something?
--
htt
Hi all,
I've made a simple cleanup which unifies all snd_pcm_hw_params_*
functions. The first set of changes are in CVS a few days, but some
developers pointed that the backwards compatibility is a right thing.
After some thoughs, I think that this sort of cleanups is good for
37 matches
Mail list logo
