Re: [ecasound] development release: 2.2.0-rc1

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [ecasound] development release: 2.2.0-rc1
From: Kai Vehmanen (
Date: Mon Dec 02 2002 - 03:11:01 EET

On Mon, 2 Dec 2002, Junichi Uekawa wrote:

>> Btw; does this new arrangement somehow conflict with the debian
>> packaging guidelines?
> Applications should ideally provide shared library,
> however that restriction has been relaxed a bit in the recent
> days.

Hmm, do let me know how critical you see this issue to be. I could add a
configure option that would build all the libs as shared. But there are
drawbacks: This would require separate code for the static and shared
builds. Also, testing that both static and shared builds work would be
very time consuming (you'd have to rebuild whole ecasound or maintain two
parallel installations all the time... for each development branch).

One additional problem is that supporting shared libs prevents me from
using the extra flexibility of static libs. For instance, unlike shared
libs, it's possible to link static libs against other static libs. In this
case libraries are used as a mechanism to collect all code located
in one directory.

One thing I'd like to do is to split the libecasound files into multiple
directories, each of which would build one libsubmod.a library. These
sublibs would be used to build the main libecasound.a. This might speed up
the compilation quite a bit (currently the final libecasound link-stage is
a real machine-killer :)). This change would also make the program
structure easier to understand. But you really can't do this with shared
libs... unless you require libecasound clients to link against n+1
different libs.

There are also other misc issues with shared libs (or more specifically,
libtool) that I'd wouldn't mind forgetting about. For instance, you can't
use non-libtool libraries as components when building libtool libraries.
Without this restrictin, it's quite easy to add libecasound/foobar-1.2
modules and just include all the code to libecasound without large-scale
makefile hacking.

A separate issue is whether to provide shared version of libecasoundc (the
C ECI implementation). This is specifically meant to be used by other
apps, so a shared version might make sense. On the other hand it's only
under 1000 lines of code, so the extra disk-space use is not much of an
issue. But I could add a separate configure option for this if needed
(basicly only thing that changes is inclusiong of the "-static" flag
in libecasoundc/

 Audio software for Linux!

New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Dec 02 2002 - 03:07:13 EET