Subject: Re: [ecasound] ecasound is now available through Debian mirrors
From: Kai Vehmanen (firstname.lastname@example.org)
Date: Tue Jan 23 2001 - 21:45:09 EET
yOn Wed, 24 Jan 2001, Junichi Uekawa wrote:
>>> I believe ecasound is available through the debian mirrors,
> and this means, I will get filed bug reports about this program not building
> on architectures that debian supports ...
> arm, ppc, sparc, sparc64, alpha, m68k, mips, (superH, hppa, and hurd-i386)
> I wonder if whether ecasound would survive the portability test.
This would be a very interesting test, but I'm afraid ecasound
wouldn't pass the test with clean papers. I say this because...
- nearly all development is done on Redhat 6.x x86 boxes
- written in C++
... I can always try to write portable code, but in some cases you just
don't know what to expect. POSIX threads are a good example. On some
platforms, the default C-library is compiled with thread-support and all
apps must be compiled with a certain define enabled (-D_REENTRANT). On
some platforms, there's a separate C-libary for threaded apps (usually
libc_r). Sometimes the pthread-functions themselves are in a separate
library (not in libc that is, usually libpthread). Some platforms require
a separate compiler switch (-pthread) ... etc, etc, and the list goes on.
It's difficult to resolve these issues beforehand.
Otherwise ecasound should be rather well portable. Most external packages
(even common stuff like OSS-support and libaudiofile) are optional and
autoconf checks are used to check for most UNIX-specific functions. Most
difficult areas are thread-support and possibly ncurses. These are the
only external packages that must exist to compile ecasound. Hmm, it might
be good to drop the ncurses dependency at some point. You wouldn't get all
features, but you'd still be able to compile libecasound.
And then as the last issue - C++ compile and runtime environments. Well,
the whole thing is just a big mess, no doubt about it. You can write
relatively portable C++, but you'll end up spending way too much time
avoiding (!) C++ features and making hacks around implementation-specific
problems. Just check the Mozilla programming guide. Arrghh! So in
ecasound, I follow the ANSI C++ spec (v3, the 1997 draft). I've avoided
some C++ features (like namespaces), but I will use things like STL,
templates and exceptions even though there are n+1 shaky implementations
out there... So as you can see, gcc 3.x really is an important step for
C++ developers. Gcc 2.x series isn't all that bad, but there is just too
much variation between releases.
-- . http://www.eca.cx ... [ audio software for linux ] /\ . . http://www.eca.cx/sculpscape [ my armchair-tunes mp3/ra/wav ]
-- To unsubscribe send message 'unsubscribe' in the body of the message to <email@example.com>.
This archive was generated by hypermail 2b28 : Tue Jan 23 2001 - 21:13:07 EET