pkg-config for alsa?

pkg-config for alsa?

[Takashi Iwai]

Hi,

i'd like to rewrite configure for alsa-utils and alsa-tools to use
pkg-config for alsa-lib.  you might have found alsa.pc already in
alsa-lib.
the only concern is that pkg-config is unlikely installed as a
standard tool in most distributions.  but surely pkg-config is the
right way to go.

also, how about to add a define "-DALSA_PCM_NEW_HW_PARAMS_API"
to cflags in alsa.pc, so that the new PCM API is chosen if someone
uses pkg-config ?  there is still alsa.m4 for the older API, so
existing applications don't suffer by this.

any comments please?


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: pkg-config for alsa?

[Pavel Roskin]

Hello!

I haven't done any development for sound in the userspace, so don't put
too much weight into my words, but for what it's worth ...

> i'd like to rewrite configure for alsa-utils and alsa-tools to use
> pkg-config for alsa-lib.  you might have found alsa.pc already in
> alsa-lib. the only concern is that pkg-config is unlikely installed as a
> standard tool in most distributions.  but surely pkg-config is the right
> way to go.

I would object if portability between operating systems was desired.  But
since L in ALSA stands for Linux, it's probably a reasonable requirement.
I believe that somebody should rewrite pkgconfig in shell, so that it
could be distributed with packages.

I have no problem with giving pkgconfig more exposure, since I'm not aware
of any alternatives.  It addresses an issue that other tools don't
address.  For example, libtool doesn't keep path to the headers.  m4
macros either do wild guessing or resolve to a supplied executable script
(like glib-config), which is worse than pkgconfig, because pkgconfig
behaves in a more predictable way than a bunch of little scripts.

> also, how about to add a define "-DALSA_PCM_NEW_HW_PARAMS_API" to cflags
> in alsa.pc, so that the new PCM API is chosen if someone uses pkg-config
> ?  there is still alsa.m4 for the older API, so existing applications
> don't suffer by this.

Maybe it's too late to comment on this, but I don't like the name of that
define.  What is new today will be old one year later.  Instead of
inventing new names, it's better to use versions of API.  The application
would define what API version is expects, and the headers would enable
corresponding API or report that the given version of API is no longer
supported.

I understand that it would be convenient to force the applications to the 
new API when they switch to pkgconfig, but it would be even better to have 
them define the API they except themselves, so that it could later be 
updated in the right place - in the applications (together with the code
that needs updating).

While at this issue, is it possible to compile everything from CVS without
intermediate installs?  I mean, compile alsa-lib against the headers of
alsa-driver in CVS and alsa-util against alsa-lib in CVS. If it's
possible, please make sure not to break this functionality.  Otherwise,
I'd like to see it added (probably through temporary rc files for
uninstalled library and drivers).

-- 
Regards,
Pavel Roskin




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: pkg-config for alsa?

[Takashi Iwai]

Hi,

At Wed, 2 Oct 2002 09:46:52 -0400 (EDT),
Pavel Roskin wrote:
> 
> Hello!
> 
> I haven't done any development for sound in the userspace, so don't put
> too much weight into my words, but for what it's worth ...
> 
> > i'd like to rewrite configure for alsa-utils and alsa-tools to use
> > pkg-config for alsa-lib.  you might have found alsa.pc already in
> > alsa-lib. the only concern is that pkg-config is unlikely installed as a
> > standard tool in most distributions.  but surely pkg-config is the right
> > way to go.
> 
> I would object if portability between operating systems was desired.  But
> since L in ALSA stands for Linux, it's probably a reasonable requirement.
> I believe that somebody should rewrite pkgconfig in shell, so that it
> could be distributed with packages.

i don't think pkgconfig breaks the portability.  but anyway, you're
right.  ALSA is, for the time being, designed only for Linux.


> I have no problem with giving pkgconfig more exposure, since I'm not aware
> of any alternatives.  It addresses an issue that other tools don't
> address.  For example, libtool doesn't keep path to the headers.  m4
> macros either do wild guessing or resolve to a supplied executable script
> (like glib-config), which is worse than pkgconfig, because pkgconfig
> behaves in a more predictable way than a bunch of little scripts.
 
yes.  i was convinced that pkgconfig does much better job than m4
kludges.


> > also, how about to add a define "-DALSA_PCM_NEW_HW_PARAMS_API" to cflags
> > in alsa.pc, so that the new PCM API is chosen if someone uses pkg-config
> > ?  there is still alsa.m4 for the older API, so existing applications
> > don't suffer by this.
> 
> Maybe it's too late to comment on this, but I don't like the name of that
> define.  What is new today will be old one year later.  Instead of
> inventing new names, it's better to use versions of API.  The application
> would define what API version is expects, and the headers would enable
> corresponding API or report that the given version of API is no longer
> supported.
 
this is the advantage to put such a define into pkgconfig stuff.
the define name is, as you pointed out, not perfect :)
but please note that this flag can be removed in near future, if most
of applications follow the new api.
since the flags via pkgconfig is parsed dynamically in configure, we
can reduce this flag even without changing the configure of each app
but just by changing the alsa.pc without this define.


> I understand that it would be convenient to force the applications to the 
> new API when they switch to pkgconfig, but it would be even better to have 
> them define the API they except themselves, so that it could later be 
> updated in the right place - in the applications (together with the code
> that needs updating).

i don't like to break the compatibility, but it's true, too, that
"the obsolete API is obsolete".  it shouldn't be used if you write a
new application.


> While at this issue, is it possible to compile everything from CVS without
> intermediate installs?  I mean, compile alsa-lib against the headers of
> alsa-driver in CVS and alsa-util against alsa-lib in CVS. If it's
> possible, please make sure not to break this functionality.  Otherwise,
> I'd like to see it added (probably through temporary rc files for
> uninstalled library and drivers).

that's what we care, too.

the kernel API (between alsa-driver and alsa-lib) is kept unchanged
since rc3.  there was a change between rc2 and rc3 (with backward
compatibility), though.
thus, upgrading alsa-kernel/alsa-driver is ok at any time (even
recommended).

the alsa-lib API was changed after rc3.  this is why the define above
is required.  and the new alsa-lib supports both new and old APIs by
versioned symbols.
hence, you can replace the new alsa-lib binary with the old (rc3)
alsa-lib one without problems (in theory).  and you can compile the
old apps with the new alsa-lib, too.

the latest alsa-utils require the latest alsa-lib because they use the
new API.

so, as conclusion, you can update independently alsa-driver and
alsa-lib.  it should be no problem.  update of alsa-utils will require
the update of alsa-lib.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Forward: Re: pkg-config for alsa?

[Takashi Iwai]

[-- Attachment #0: Type: message/rfc822, Size: 1152 bytes --]

From: Paul Davis <pbd@op.net>
To: Pavel Roskin <proski@gnu.org>
Cc: Takashi Iwai <tiwai@suse.de>, alsa-devel@lists.sourceforge.net
Subject: Re: [Alsa-devel] pkg-config for alsa?
Date: Wed, 02 Oct 2002 10:03:44 -0400
Message-ID: <20021002135925.6AE4A146A9@Cantor.suse.de>

   [ please forward to alsa-devel@lists.sourceforge.net ]

>While at this issue, is it possible to compile everything from CVS without
>intermediate installs?  I mean, compile alsa-lib against the headers of
>alsa-driver in CVS and alsa-util against alsa-lib in CVS. If it's
>possible, please make sure not to break this functionality.  Otherwise,
>I'd like to see it added (probably through temporary rc files for
>uninstalled library and drivers).

pkgconfig supports the --uninstalled flag, which will do the right
thing if the *.pc file supports it. takashi just has to define this.

--p



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf