Re: [linux-audio-dev] "pro" soundfile editors for linux

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

Subject: Re: [linux-audio-dev] "pro" soundfile editors for linux
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ti helmi  08 2000 - 11:59:39 EST


>Another problem is compile-time and inter-library compatibility
>problems. Most problem-reports I receive are either g++ or
>libstc++ related. And taking your Quasimodo as an example, I've
>never been able to compile it. Same goes with aRts. And believe me,

I understand this issue, and am very concerned about it. But I don't
think it has too much to do with C++ per se. Its also a feature of,
for example, many GNOME and KDE programs, which is one reason why I've
tried to stay away from both of them.

There is this general issue that we in the open source community face
a lot these days: there are libraries out there that do things we
want. They come in nice neat packages. They work. But if we use them,
we have to tell both compile-oriented users *AND* people using
non-statically linked binaries "you need this library". And that
library. And the other library. And that one over there. Worse, when
the libraries alter, we face the problem of either keeping up with
them in our apps, or telling people "use an older version". In some
cases, we have to tell them "use the new version". Its an ugly, ugly
mess.

However, I am not convinced that its worse that the most obvious
alternative: building the source code of all these different libraries
into a single application.

An intermediate strategy is to always distribute statically linked
binaries. This avoids people from having to download anything in order
to use the program.

But am I certain that this is a generic problem that is inevitable as
libre/free/open source software evolves, and we increasingly turn to
libraries for useful functionality.

Can any C++ programmer who has ever used libsigc++ ever imagine doing
with it ? Can anyone who has used the STL imagine working without it ?
Sarcastic answers aside, libraries like these are vital components of
our working environment. Likewise, I grew so tired of cooking up error
reporting functions that did more than "fprintf (stderr, ...)" that I
now require all programs that I write to use my own library, libpbd,
which contains such things, as well as many other useful functions
(pthread spinlocks, path scanners, memory allocation objects,
select(2) objects, etc.)

I don't want to go back to self-contained applications, but I am also
very concerned about the issue that Kai raises.

--p


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

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST