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 _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
