1
------------------------------------------------------------------------
4
(edi-30): Turning libecasound and libkvutils into static libraries.
5
- submitted: kaiv, 08.10.2002
6
- initial implementation: kaiv, 16.10.2002
7
- done: kaiv, 29.10.2002
9
------------------------------------------------------------------------
12
- rationale: see below
14
- shared versions of libecasound and libkvutils are never installed
15
- ecasound, ecamegapedal, ecawave and other apps that require
16
direct access to libecasound should use static linkage (but _not_
17
necessarily to other libs than libecasound and libkvutils)
18
- ecasound-plugins are linked statically to the binaries
20
- utils in the ecatools package should be rewritten using
22
- new ecasound packages
23
- runtime: ecasound binary, ECI apps, documentation and
25
- devel: header files and .a libraries (libecasound + libkvutils)
27
------------------------------------------------------------------------
28
[kaiv on ecasound-list, 08.10.2002]
30
First of all, if you think this is a very bad way to go, do let me know.
31
This request is aimed especially to those of you who are involved with
32
distribution issues. I'll consider silence as 'I agree'. :) Ok, let me
37
The current ecasound development model does not work very well. Nowadays
38
it's simply impossible for me to spend long periods of time on ecasound
39
development. I still have time for it, but it's just much more irregular.
40
The common scenario nowadays is that I spent a hectic day or two
41
implementing some new feature, and then have to return to other tasks.
42
After a month or so the cycle repeats.
46
With the current model, the development series just never gets enough
47
testing. As it is now, most ecasound users are using the stable branch.
48
Only very few people actively use the development versions. This means I'm
49
getting very little feedback concerning the new features, especially when
50
compared to the huge amount of functionality that ecasound nowadays
53
A prime example of this is that yesterday, when doing some multitrack
54
recording with the latest 2.1dev12, I noticed a huge bug in the
55
multitrack-mode code. It turned out that ecasound would stop processing if
56
all inputs tracks became finished, _even though_ we were still recording a
57
live input. The fact that a bug of this magnitude has gone unnoticed for
58
many _months_ makes me very, very, very uncomfortable about the status of
59
the current development branch.
63
During the last year or so I've tried to find a cure to this problem. I've
64
spent lots and lots of time with library versioning issues, defining roles
65
for different branches, change control, developer documentation and other
66
stuff that doesn't directly benefit the normal end-users of ecasound
69
I've also tried to attack the problem with testing. I've written separate
70
test tools for libecasound and libecasoundc, a general testsuite and
71
various smaller tools. These have helped a lot, but in the end, testing
72
just doesn't replace real-life use.
74
At the same time, the reality is that aside ECI apps, _nobody_ is using
75
ecasound as a platform. So most of this work is just wasted effort. And
76
this isn't a problem of slow adoption. Although released versions of
77
libecasound have been available for over two years, the only applications
78
using it are ecawave and ecamegapedal (both written by me). Maintaining
79
the whole shared-library thing going on for just these two,
80
not-so-widely-used apps just doesn't seem sensible.
82
4. Improvement Proposal
84
Inspired by the recent work on standalone ECI implementations, I'd like to
85
drop the whole ecasound-as-a-platform concept, and instead, continue
86
developing ecasound as an application. Only supported way of using
87
ecasound as a development platform would be ECI.
91
- only one code-branch (no more separate stable and development
92
releases; just releases and CVS-access for bleeding-edge development)
93
- removal of all shared libraries (libkvutils and libecasound)
94
- ecasound binary would be statically linked against libkvutils
95
and libecasound, but dynamically against other libraries
96
- ecatools have to be rewritten using ECI (otherwise
97
we'd have too many multi-megabyte binaries :))
98
- ecawave and ecamegapedal have to be linked statically (this
99
isn't that big of a problem, I'm quite sure the few people
100
on this planet that use all these three apps can
101
sacrifice the harddrive space for three copies of libecasound
104
------------------------------------------------------------------------
added
removed
Documentation/archived/edi-30.txt
