Thread: [Audacity-devel] sbsms compilation
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Clayton O. <cla...@gm...> - 2008-11-26 02:01:09
|
I don't have a linux machine to test on right now. I'll try to piece one together in the next few days and resolve all of the compilation problems. For now I guess just disable sbsms in the configuration as a workaround on linux. |
From: Richard A. <ri...@au...> - 2008-11-29 17:36:43
|
On Tue, 2008-11-25 at 17:53 -0800, Clayton Otey wrote: > I don't have a linux machine to test on right now. I'll try to piece > one together in the next few days and resolve all of the compilation > problems. For now I guess just disable sbsms in the configuration as > a workaround on linux. 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: http://www.audacityteam.org/wiki/index.php?title=CVS_Etiquette 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) 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. Comparing to the SVN version, sbsms-notapplegcc.patch is already applied, the rest of the work seems to need doing there as well, all the patches apply as-is (need to be followed with the usual incantations to update autotools generated files). Richard |
From: Clayton O. <cla...@gm...> - 2008-11-29 20:59:42
|
> > 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. |
From: Richard A. <ri...@au...> - 2008-12-01 22:05:52
|
On Sat, 2008-11-29 at 12:59 -0800, Clayton Otey wrote: > 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. For small changes that's about all there is. If you find yourself doing a major update from one to the other I have a procedure documented in the bottom of lib-src/audacity-patches.txt for for working out which files have changed / been added / been removed in a newer upstream version. For this to work you have to keep track of any local patches included in Audacity CVS otherwise they get lost at each upgrade, hence why various patches are committed to audacity CVS. > > 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. No problem having all the source code in audacity CVS. There would still be an advantage to disable building the programs as it speeds up the build significantly (we can do this from the Audacity configure script). It would also make packaging for Linux distributions a bit easier, because the libsbsms package then has no optional dependencies, and the programs (with the WX and PortAudio deps) don't have to be installed in order to compile against the libs. Richard |