Re: [Audacity-devel] sbsms compilation

[Clayton O. <cla...@gm...>]

>
> Fair enough. Which is the authoritative version of sbsms to generate
> patches against? What is in audacity CVS seems to match sbsms SVN on

sourceforge, do you have a mechanism for keeping the two in sync? The
> way the rest of the external libraries in lib-src are managed is
> described at the bottom of this wiki page:
>

The current version of sbsms is 1.7.0 and the svn should match what's in
audacity cvs, as you said, but not what's released on sourceforge.  Patches
to sbsms should be made against whatever is in svn at the moment, and I can
figure out how to resolve the patch if there are any issues.  Right now my
method for keeping sbsms/audacity in sync is a wonderful tool called cp.  If
anybody has any better ideas, I'd love to hear them.

I've had a go through and cleaned up most of what is needed in
> lib-src/sbsms/
> * remove the following generated files from CVS: config.status, libtool,
> aclocal.m4, sbsms.pc, src/libsbsms.la, libsbsms.spec
> * apply the attached sbsms-gcc4.patch to fix missing C++ headers
> * apply the attached sbsms-notapplegcc.patch which removes the Apple
> GCC-specific option from AM_CFLAGS (note if this is needed on Apple
> platforms then a test needs to go in configure to add the flag as
> needed, I can write such a test if needed)


Thank you.  I was just about to go in and do all of this myself.  The
patches have been incorporated into the sbsms svn.

The compile error occurs in src/convert.cpp, which isn't used at all in
> audacity, it's only needed as part of the stand-alone sbsms programs. So
> what is really needed is some options to configure to disable building
> the applications and only get the libraries (or in extremis, separation
> of the library from the applications. Just disabling all the current
> deps doesn't work, because sbsms is still built). Only the library code
> then has to be distributed and made portable to all Audacity's
> platforms.

It turns out that getting automake to generate the correct rules for
> this isn't that hard, hence sbsms-optional-progs.patch, which adds a new
> option to configure to disable building all the programs, leaving only
> the libraries. This defaults to enabled (so you get whatever programs
> you have libs to build), but can be disabled, at which point the Linux
> build works correctly.
>

I never got a linux machine working.  Instead, I just built gcc 4.3.2 on my
mac, which should suffice.  I got convert.cpp to compile easily enough, and
the build now works with a plain ./configure.

I'd prefer to distribute exactly what's in the sourceforge sbsms release as
it is, with all files in one package, rather than distribute only the
library files in audacity, since it is easier to maintain that way.  Does
this sound OK?  After all, sbsms is supposed to be just as platform
independent as audacity.