On Mon, 23 Apr 2007, Chris Bagwell wrote:
> I'll leave it up to you guys on what to do... I'm fine with either.
Since I am now pretty much done, I'll commit.
> I've been extremely busy and so didn't get to do the pre-release yet. I
> had a few TODO's I wanted to do plus kept seeing submissions so silently
> held off.
As far as your TODOs go, that's up to you, but please tell us "stop!" if
we're committing things that will hold up a release. All that I've seen
recently has been of the non-destabilising sort (if you agree with my
opinion that having experimental-quality formats and/or effects in a release
is not a problem).
> 1) Get sunaudio.c working automatically. I have to add -x to "-t sunau
> /dev/audio" on solaris to play 16-bit data. I haven't had time to
> understand the new (to me) reverse_bytes stuff to see whats needed. I've
> pretty much convinced myself though that endian problems are limited to
> sunaudio.c on Solaris.
Have you tested on Solaris x86 vs SPARC? i.e. it could be a problem for all
Sun audio drivers, or it could be an endian-specific problem. In either
case, it should be trivial to fix.
> Overall, SoX 14.0.0 is running much nicer on Solaris compared to 13.0.0.
Great. Hopefully the new code is also easier to understand.
> 2) I want to resurrect the libsox-config script. Short of someone's
> configure script parsing the output of "ldd libso.so", I see no sane way
> to detect all the optional libraries that libsox may or may not be
> linked to so that they can update their LDFLAGS appropriately.
> Also, I prefer the libsox-config approach to picky pkg-config because a)
> pkg-config seems overkill and doesn't add any improvements that I can
> find beyond the libxxx-config approach. b) pkg-config seems to require
> installing sox with root permissions to be useful to most people and I
> personally do not have root access to all the platforms I develop on. c)
> so far I've only had bad experience with referencing pkg-config in sox's
> own configure.ac.
My 2¢: pkg-config is to libfoo-config as autoconf is to writing configure
scripts by hand. You don't have to install with root permissions; just like
everything else, pkg-config can be given environment variables pointing to
users' personal installation directories. Your "bad experience" came about
by not wanting to install pkg-config in order to build SoX. I sympathise
with not wanting to install yet another tool, but pkg-config does seem to be
attracting widespread support, and I'd rather just write one pkg-config
configuration than need to build up my own imperfect understanding of how it
works internally (which is what I'd need to do to write a proper working
If we used pkg-config for SoX, we could also use it for libsndfile (it's not
logically necessary, but it would seem hypocritical not to), and get rid of
another bunch of hackery in our build system.
I think there's a general point here: when I decide to use another tool in a
software project, 9 times out of 10 I just say "wajig install tool". For
systems that don't have some sort of package repository (Linux) or ports
collection (BSD), that's a pain. As far as our users go, this mostly means
(non-Cygwin) Windows, and how many of those use mingwin (rather than the
win32 build system) anyway? Solaris has various 3rd party ports collections
available. I can't think of another mainstream modern OS that is a problem.
I would rather solve this problem, if necessary, by making a collection of
mingw ports of the various dependencies, rather than by making our build
system more complex.
lawyer, n. one paid to make the inexcusable incomprehensible