I’ve been asked to announce something I’ve been working on here.
If all goes as foreseen, Mac users will (soon, pending testing/approval) have the option to install Audacity through MacPorts.
MacPorts requires minimal terminal/command line skills, but comes with two main advantages:
Audacity will use shared versions of most of its dependencies rather than installing its own copy. In addition, those resources (and Audacity itself) will be kept up to date through MacPorts’ semi-automatic updating mechanism.
64bit systems will get a full 64bit build against the current platform SDK, which should provide compatibility with ditto AudioUnits, increase stability, processing performance and allow to work with larger projects.
This way of installation will not be supported officially by the Audacity team, but support for MacPorts-related issues will of course be available through trac.macports.org .
So basically I’ve just wasted half a day or so… trying to build it myself here on the latest OSX and Xcode Interesting exercise, but fraught with old code and pitfalls that seemed bottomless.
So, native 64bit and latest SDK huh. Sounds good.
I’ll be interested to see how clean a build it is.
What do you mean with “how clean a build it is”? Maybe you’ll find it’s not clean at all because I patch at least 1 Makefile.in rather than patching configure.ac and/or Makefile.am and then re-running autoconf .
The build system would very likely be much cleaner if it were based on cmake (at least for Audacity’s own code).
One thing I didn’t mention but that follows more or less from the using shared resources (libraries) instead of bundling own copies : the MacPorts Audacity app bundle will not be standalone. You will be still able to move it from its designated install location (/Applications/MacPorts), but that is not really supported by MacPorts, and the copy can stop functioning at each update of a dependency.
Another thing I forgot to mention: I’ve also thrown in an en_GB translation.
@cyrano:
Credit where credit is due: I had to fix only a very small number of remaining issues (mostly unconditional references to 32bit/Carbon-only symbols) to get the 64bit build to complete; the A-team did most of the work already.
My previous efforts to build 2.1.0 against wxGTK 2.8/64 on OS X were much more … interesting
Interesting exercise, but fraught with old code and pitfalls that seemed bottomless.