[opus] libopusfile
Timothy B. Terriberry
tterribe at xiph.org
Sun Sep 23 18:29:59 PDT 2012
Diego Elio Pettenò wrote:
> Would a ./configure --enable-debug-build work as well for you?
It's a lot more painful to use than make clean ; make debug
> Generally speaking I'd suggest keeping debug info and debug code paths
> (assertion etc.) orthogonal as much as possible: it's handy for
> distributions such as RHEL (and for Gentoo as well) to be able to have
> debug symbols on a release, optimized build in case something goes wrong
> and the library crashed.
Yes, I have no problem with debug info being enabled in optimized builds
by default (I like getting useful backtraces from clueful users). It's
disabling optimizations and enabling assertions that I care about.
> So my suggestion would be: by default keep assertions in (that's what
> most software seem to do since assert.h only compiles them out if you
> build -DNDEBUG), leave the user the ability to specify their cflags, and
> then have the debug codepaths enabled by -DDEBUG or something.
That's not how libopusfile uses assertions (and it does not use assert.h
for that reason, among others). They're used to assert things that
should be truly impossible unless there is a bug, and not, e.g., to
avoid having to handle errors, etc. This is useful for automated testing
and to suppress false positives in static analysis tools. Some of them
are quite expensive (e.g., they perform additional file I/O), and should
not be enabled by default.
libopus has exactly the same policy, by the way.
> --enable-debug-build would append -ggdb to the flags (for GCC at least),
> together with -UNDEBUG -DDEBUG to make sure that both assertions and
> codepaths are enabled. (-UNDEBUG because there's actually a
> --disable-assert option that one can add to ./configure as part of
> standard autoconf)
Right now, nothing in the code uses #ifdef DEBUG or #ifdef NDEBUG, and I
doubt anything ever will. I wouldn't want my policy on what those should
cover to interfere with the policy of some larger project (on non-Linux
systems) that wants to incorporate the code wholesale (instead of
linking to it as an external library).
More information about the opus
mailing list