submission: audacity

[RJVB (René Bertin)]

I don't think I have to introduce Audacity to anyone here. What many may not realise though is that Audacity uses wxWidgets 2.8 (even the current 2.1.0 release candidate), which means it cannot run in native, 64bit mode (and is tricky to build on OS X versions newer than 10.6). I think an audio editor can reap many benefits from running in 64bit, so I spent some time figuring out how to build Audacity against port:wxgtk-2.8, which *does* allow 64bit builds. The result is attached. Lost in the process are only 2 things:

• QuickTime import, which depends on QuickTime. Sadly inevitable as QT is 32bit only and the SDK is no longer shipped.
• AudioUnit plugins. This is only because those depend on a UI that uses platform-specific APIs. An experienced wxWidgets programmer may actually be able to port that to something that builds against wxGTk.

The shared libraries aside (MP3Lame and the FFMpeg libav libraries) I have tried to preserve as many of the data and config locations as possible, so that this and the Audacity "distribution version" share as much as possible.

This port uses port:portaudio and depends on a new patch for that port which has been submitted (#47172). There are a few required components which are not in MacPorts and for which a local version is used: libsms, libsoxr, libvamp, portsmf and widgetextra. Audacity's configure script will detect and use the "system" versions when available, so it will be easy to adapt the port if any of these are considered useful beyond Audacity and added to MacPorts.

See:

• ​https://github.com/RJVB/mp-port-repository/tree/master/audio/audacity
• ​https://github.com/RJVB/mp-port-repository/tree/master/audio/audacity-devel

[RJVB (René Bertin)]

this "hacks in" code that should have been inside #ifdef APPLE blocks...

[RJVB (René Bertin)]

all patches in a convenient tarball

[RJVB (René Bertin)]

PS: I also added a "European English" translation.

[mojca (Mojca Miklavec)]

Cc Me!

[mojca (Mojca Miklavec)]

Now that you already made so much effort trying to make the software work with MacPorts: would you mind taking a look at Debian patches for wxWidgets 3.0? I would really like to avoid increasing the number of wxWidgets 2.8 dinosaurs in our package repository if that can be avoided.

​http://anonscm.debian.org/cgit/pkg-multimedia/audacity.git/tree/debian/patches

[mojca (Mojca Miklavec)]

Not that any of them are relevant here, but there are currently a lot of messages in the archive from a relatively recent discussion:

• [Audacity-devel] OSX Build - Has the Situation Improved?

(​https://sourceforge.net/p/audacity/mailman/audacity-devel/; I'm not sure how to link to a thread.)

[RJVB (René Bertin)]

Well, the 1st (topmost) comment in that thread states rather clearly that wxWidgets 3 support is still a way off (future music :))

I'll have a look at those patches, but could you at least do me the favour to try to figure out how well things work with those patches?

As to 2.8 dinosaurs ... how complicated is it to build wxGtk-2.8? If it isn't, I'd be very much in favour of keeping it around because it doesn't exist only for the sake of wxWidgets ports in MacPorts. Ports like wxWidgets, Qt, GTk etc. also have value to people using software not in MacPorts, and which may not be maintained and thus depend on old versions.

[mojca (Mojca Miklavec)]

Forget for a moment about the thread in wxWidgets. (Just take a look at instructions for building for Mac.)

I don't yet understand why Debian patches haven't made it into upstream yet (it would help a lot if they did), but the fact that Debian uses that patch and got rid of wxWidgets 2.8 says something to me. I don't think that all the Debian users would be live happily with a broken piece of software. That can happen in MacPorts community where users still have alternatives, but it is a lot less likely for Debian.

How complicated is it to build wxGtk-2.8?

It (still) works out of the box. But that doesn't change the fact that I would like to get rid of dependencies on wxWidgets 2.8 inside MacPorts.

Could you at least do me the favour to try to figure out how well things work with those patches?

I expect it to work more or less flawlessly on Linux and with some minor problems on OS X (that we should probably be able to sort out). But testing that needs a bit of work:

• given that you used github.setup RJVB audacity 5195646 I would expect that some modifications of the patch would be needed
• maybe some of the patches even conflict with your patches

In any case someone needs to take some extra time to prepare a patch. (I didn't even try to install your version of the port yet.) I could help, but I need to do some higher priority tasks (outside of MP) first.

[RJVB (René Bertin)]

Replying to mojca@…:

Forget for a moment about the thread in wxWidgets. (Just take a look at instructions for building for Mac.)

Those are very much centred on using Xcode, and are generally out of date (depending on which instructions you read...)

I don't yet understand why Debian patches haven't made it into upstream yet (it would help a lot if they did), but the fact that Debian uses that patch and got rid of wxWidgets 2.8 says something to me. I don't think that all the Debian users would be live happily with a broken piece of software. That can happen in MacPorts community where users still have alternatives, but it is a lot less likely for Debian.

I haven't checked if the Audacity Team provides a Linux installer, have you?

• given that you used github.setup RJVB audacity 5195646 I would expect that some modifications of the patch would be needed

That's just the 2.0.6 release. The tarball that can be downloaded is not as complete as the one in SVN, and since their repo is hosted by Google I preferred to host the code in a location that isn't bound to change.

• maybe some of the patches even conflict with your patches

Quite likely, The way to proceed would be to apply the Debian patches (probably all of them when we're at it, except any that are related to ALSA or other Linux-specific things). Then, see which of my patches are still relevant and if they still apply.

Most of the patches are to include code that should have been #ifdef __APPLE__ instead of #ifdef __WXMAC__; I even had to apply those concerning double-buffering (without it the level meters had corrupted backgrounds).

In any case someone needs to take some extra time to prepare a patch. (I didn't even try to install your version of the port yet.) I could help, but I need to do some higher priority tasks (outside of MP) first.

I'll see if I have some time to set up the skeleton for a audacity-devel port (containing an audacity-gtk subport) over the next couple of days. I just don't want to spend too much time on this, for learning wxWidgets for instance. My initial goal was just to have a functional 64bit build for my personal use, the fact I created a port for it was mostly because out of maintenance considerations (you know, a great way to record "how I got this to build and run" for future reference and reuse ;))

[RJVB (René Bertin)]

Set optional libraries that don't exist as ports to "local" (= included in the Audacity source tree) explicitly.

[RJVB (René Bertin)]

I had a look at the wxWidgets 3.0 version, which happens to be in Kubuntu 15.04 too, for which I have a VM. And I managed to get the same version in my PPA for Kubuntu 14.04LTS.

The result gives me some doubts to the tolerance of the average Debian user: see the attached screenshot: the playback and recording drop-downs don't work. The screenshot is from my VM, but the same happens on my real silicon rig under 14.04, where I can confirm that Audacity 2.0.5 built against wxGTk 2.8 works perfectly fine.

Also, I couldn't get it to build with clang.

[mojca (Mojca Miklavec)]

Other than those glitches: is the software usable at least? I usually created two variants, one with +wxWidgets30 and one with +wxgtk28. So users could pick which one they want and potentially contribute more patches (not that anyone did).

Replying to rjvbertin@…:

Replying to mojca@…:

Forget for a moment about the thread in wxWidgets. (Just take a look at instructions for building for Mac.)

Those are very much centred on using Xcode, and are generally out of date (depending on which instructions you read...)

​http://wiki.audacityteam.org/wiki/Building_On_Mac They basically say "Install an old OS, install Xcode 3, (maybe upgrade the OS), use Xcode 3 to build everything". But then again there is probably no sane way to use any newer version of Xcode if they don't bother switching to wxWidgets 3.0.

I haven't checked if the Audacity Team provides a Linux installer, have you?

I didn't find anything.

• maybe some of the patches even conflict with your patches

Quite likely, The way to proceed would be to apply the Debian patches (probably all of them when we're at it, except any that are related to ALSA or other Linux-specific things). Then, see which of my patches are still relevant and if they still apply.

Most of the patches are to include code that should have been #ifdef __APPLE__ instead of #ifdef __WXMAC__; I even had to apply those concerning double-buffering (without it the level meters had corrupted backgrounds).

The changes from #ifdef __WXMAC__ to #ifdef __APPLE__ only affect wxgtk (but yes, that includes wxgtk-3.0; and if they accept patches, it might be helpful to try to send those patches to them).

(Debian's patches for 3.0 could be applied to +wxWidgets30 and your patches could be applied to +wxgtk28 if you created two variants for Audacity. For a moment there might even be no need to merge those two patches.)

[RJVB (René Bertin)]

Replying to mojca@…:

Other than those glitches: is the software usable at least?

Those glitches make a rather important feature of the application unusable, so when I saw that I actually didn't insist testing it. I haven't had the time yet to try the Debian patches on OS X, and an exchange with Audacity's main OS X maintainer didn't really increase my motivation to start something that rings too many "wasting time" bells.

They basically say "Install an old OS, install Xcode 3, (maybe upgrade the OS), use Xcode 3 to build everything". But then again there is probably no sane way to use any newer version of Xcode if they don't bother switching to wxWidgets 3.0.

Not if you want to build 64bit support, no.

The changes from #ifdef __WXMAC__ to #ifdef __APPLE__ only affect wxgtk (but yes, that includes wxgtk-3.0; and if they accept patches, it might be helpful to try to send those patches to them).

I must (already...) have forgotten the implications of WXMAC: why would those changes only affect wxgtk? Because the changes I made do (which would be kind of logical given that I was building against wxgtk ...) or because wxgtk doesn't define the token?

(Debian's patches for 3.0 could be applied to +wxWidgets30 and your patches could be applied to +wxgtk28 if you created two variants for Audacity. For a moment there might even be no need to merge those two patches.)

Debian's patches will concern wxgtk code, of course, so I'm not sure if it'd be wise to try to use them for building against the native wxWidgets!

[mojca (Mojca Miklavec)]

Replying to rjvbertin@…:

The changes from #ifdef __WXMAC__ to #ifdef __APPLE__ only affect wxgtk (but yes, that includes wxgtk-3.0; and if they accept patches, it might be helpful to try to send those patches to them).

I must (already...) have forgotten the implications of __WXMAC__: why would those changes only affect wxgtk? Because the changes I made do (which would be kind of logical given that I was building against wxgtk ...) or because wxgtk doesn't define the token?

wxGTK doesn't define __WXMAC__. But developers assumed that every Mac user should be using Carbon (now Cocoa) and that GTK backend was just for Linux, so as a consequence they used "ifdef __WXMAC__ everywhere to test for a Mac. Truth to be told ... it's almost impossible to write the code properly without actually testing wxGTK on Mac.

Examples:

• wxWidgets on Mac define __WXOSX__
• wxWidgets with a GTK backend define __WXGTK___, different definitions for the Windows backend, the X11 backend etc.
• __WXMAC__ is an outdated definition (newer versions define both __WXMAC__ and __WXOSX__; the latter should be used for new software, __WXMAC__ is there just for compatibility)
• there are a few other definitions like wxOSX_USE_COCOA, wxOSX_USE_IPHONE etc.

Any "sane Mac user" would want to use Carbon/Cocoa. (Who on earth would want to install wxGTK? I mean: who would even be crazy enough to install it if we forget about package managers like MacPorts. And even in MacPorts wxGTK has almost never been used until the big split, except in a port or two that were supposed to work on FreeBSD or Linux or something.) This changed a while after Apple stopped supporting Carbon and when people realized that using wxGTK 2.8 was the only way to be able to use apps depending on wxWidgets 2.8.

[RJVB (René Bertin)]

Replying to mojca@…:

Any "sane Mac user" would want to use Carbon/Cocoa.

Well, for any sane Mac users who prefer the toyish looks of wxWidgets/Cocoa combined with unsupported (by the Audacity team) patches to use wxWidgets 3:

​https://github.com/RJVB/mp-port-repository/tree/master/audio/audacity-devel

Both the wxGTk (+wxgtk) and Cocoa variants of Audacity 2.0.6 show the glitch also seen under Linux, though the Cocoa (wxWidgets) variant provides handles that make it still possible to use the dropdown menus. Other than that, these builds are less than ideal which is why I publish them as a -devel port:

• the Cocoa build is set up (hardwired) to expect its various files in an OS X-style location ({,~}/Library/Application Support), but the standard build used currently generates a "legacy" ${prefix}/bin/audacity executable and installs files in XDG/linuxy locations. As a results, libmp3lame isn't found (ffmpeg was maybe found by chance on my system), nor are the Nyquist plugins. The libraries can be configured through the preferences dialog, but not the plugins AFAIK.

• the wxGTk build has other displaying issues (apart from the aforementioned glitch), possibly due to wxGtk 3 using GTk 3 instead of 2.

• the Cocoa build doesn't provide any additional functionality, maybe even less. I've had to deactivate several code-paths (including the AudioUnits support) because they depended on Carbon APIs which are deprecated/obsolete and not available in 64bit.

If anyone who wants to have a go at addressing these issues, be my guest, but I suggest we wait until the Audacity Team do their own port to wxWidgets 3. It's on their ToDo list, so any effort we make will be redundant (and undoubtedly inferior as we'd be patching instead of revisiting code we know more or less intimately).

[mojca (Mojca Miklavec)]

Something weird about the compiler:

=== configuring in lib-src/libsoxr (/path/to/audacity/work/audacity-5195646/lib-src/libsoxr)
configure: running /bin/sh ./configure --disable-option-checking '--prefix=/opt/local'  '--enable-shared' '--enable-sse' '--disable-audiounits' '--disable-dependency-tracking' '--disable-quicktime' '--disable-static' '--disable-universal_binary' '--with-ffmpeg' '--with-lam' '--with-libflac' '--with-libmad' '--with-libsoxr=local' '--with-libvamp=local' '--with-libvorbis' '--with-lv2=local' '--with-sbsms=local' '--with-soundtouch' '--with-twolame' '--with-widgetextra' 'CPPFLAGS=-I/opt/local/include' 'WX_CONFIG=/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/bin/wx-config' 'CC=/usr/bin/clang' 'CFLAGS=-pipe -Os -arch x86_64' 'LDFLAGS=-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64' 'CXX=/usr/bin/clang++' 'CXXFLAGS=-pipe -Os -arch x86_64 -stdlib=libstdc++' '--with-wx-config=/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/bin/wx-config' '--enable-static=yes' '--enable-shared=no' '--disable-programs' '--disable-programs' --cache-file=/dev/null --srcdir=.
-- The C compiler identification is AppleClang 4.2.0.4250028
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -- works

[mojca (Mojca Miklavec)]

Another problem. I have python3 enabled by default and lib-src/lv2/lv2/waflib/Scripting.py fails to configure:

Traceback (most recent call last):
  File "waf", line 162, in <module>
    from waflib import Scripting
  File "/path/to/audacity/work/audacity-5195646/lib-src/lv2/lv2/waflib/Scripting.py", line 6, in <module>
    from waflib import Utils,Configure,Logs,Options,ConfigSet,Context,Errors,Build,Node
  File "/path/to/audacity/work/audacity-5195646/lib-src/lv2/lv2/waflib/Utils.py", line 275
    except OSError ,e:
                   ^
SyntaxError: invalid syntax

The expression except OSError ,e has to be replaced by except OSError as e (also at a couple of other places), but more importantly maybe the python version should be more deterministic than "#! /usr/bin/env python".

[RJVB (René Bertin)]

Replying to mojca@…:

Something weird about the compiler:

What's weird about that? It's not the 1st time I see cmake or a comparable build system normalise links. Supposing that's what happens ...

[RJVB (René Bertin)]

Replying to mojca@…:

Another problem. I have python3 enabled by default and lib-src/lv2/lv2/waflib/Scripting.py fails to configure:

...

The expression except OSError ,e has to be replaced by except OSError as e (also at a couple of other places), but more importantly maybe the python version should be more deterministic than "#! /usr/bin/env python".

Didn't notice that as I still have 2.7 as the default python version. In fact, I didn't notice any Python code at all (I did have a blast to a distant past when I saw a directory called xlisp ... :))

Did you have a look at the Python code in waflib? If it's clearly pre-py3 code I propose to ensure a 2.7 interpreter is used.

[mojca (Mojca Miklavec)]

libtool: link: /usr/bin/clang++ -I../lib-src/portmixer/include -I../mac -pipe -Os -arch x86_64 -stdlib=libstdc++ -Wall -I../lib-src/FileDialog -rdynamic -Wl,-headerpad_max_install_names -arch x86_64 -o audacity audacity-BlockFile.o audacity-DirManager.o audacity-Dither.o audacity-FileFormats.o audacity-Internat.o audacity-Prefs.o audacity-SampleFormat.o audacity-Sequence.o blockfile/audacity-LegacyAliasBlockFile.o blockfile/audacity-LegacyBlockFile.o blockfile/audacity-ODDecodeBlockFile.o blockfile/audacity-ODPCMAliasBlockFile.o blockfile/audacity-PCMAliasBlockFile.o blockfile/audacity-SilentBlockFile.o blockfile/audacity-SimpleBlockFile.o xml/audacity-XMLTagHandler.o audacity-AboutDialog.o audacity-AColor.o audacity-AudacityApp.o audacity-AudacityLogger.o audacity-AudioIO.o audacity-AutoRecovery.o audacity-BatchCommandDialog.o audacity-BatchCommands.o audacity-BatchProcessDialog.o audacity-Benchmark.o audacity-CaptureEvents.o audacity-Dependencies.o audacity-DeviceManager.o audacity-Envelope.o audacity-FFmpeg.o audacity-FFT.o audacity-FileIO.o audacity-FileNames.o audacity-FreqWindow.o audacity-HelpText.o audacity-HistoryWindow.o audacity-ImageManipulation.o audacity-InterpolateAudio.o audacity-LabelDialog.o audacity-LabelTrack.o audacity-LangChoice.o audacity-Languages.o audacity-Legacy.o audacity-LoadModules.o audacity-Lyrics.o audacity-LyricsWindow.o audacity-Matrix.o audacity-Menus.o audacity-Mix.o audacity-MixerBoard.o audacity-PitchName.o audacity-PlatformCompatibility.o audacity-PluginManager.o audacity-Printing.o audacity-Profiler.o audacity-Project.o audacity-RealFFTf.o audacity-RealFFTf48x.o audacity-Resample.o audacity-RingBuffer.o audacity-Screenshot.o audacity-Shuttle.o audacity-ShuttleGui.o audacity-ShuttlePrefs.o audacity-Snap.o audacity-SoundActivatedRecord.o audacity-Spectrum.o audacity-SplashDialog.o audacity-SseMathFuncs.o audacity-Tags.o audacity-Theme.o audacity-TimeDialog.o audacity-TimerRecordDialog.o audacity-TimeTrack.o audacity-Track.o audacity-TrackArtist.o audacity-TrackPanel.o audacity-TrackPanelAx.o audacity-UndoManager.o audacity-VoiceKey.o audacity-WaveClip.o audacity-WaveTrack.o audacity-WrappedType.o commands/audacity-AppCommandEvent.o commands/audacity-BatchEvalCommand.o commands/audacity-Command.o commands/audacity-CommandBuilder.o commands/audacity-CommandDirectory.o commands/audacity-CommandHandler.o commands/audacity-CommandManager.o commands/audacity-CommandSignature.o commands/audacity-CommandType.o commands/audacity-CompareAudioCommand.o commands/audacity-ExecMenuCommand.o commands/audacity-GetAllMenuCommands.o commands/audacity-GetProjectInfoCommand.o commands/audacity-GetTrackInfoCommand.o commands/audacity-HelpCommand.o commands/audacity-ImportExportCommands.o commands/audacity-Keyboard.o commands/audacity-MessageCommand.o commands/audacity-OpenSaveCommands.o commands/audacity-PreferenceCommands.o commands/audacity-ResponseQueue.o commands/audacity-ScreenshotCommand.o commands/audacity-ScriptCommandRelay.o commands/audacity-SelectCommand.o commands/audacity-SetProjectInfoCommand.o commands/audacity-SetTrackInfoCommand.o effects/audacity-Amplify.o effects/audacity-AutoDuck.o effects/audacity-BassTreble.o effects/audacity-Biquad.o effects/audacity-ChangePitch.o effects/audacity-ChangeSpeed.o effects/audacity-ChangeTempo.o effects/audacity-ClickRemoval.o effects/audacity-Compressor.o effects/audacity-Contrast.o effects/audacity-DtmfGen.o effects/audacity-Echo.o effects/audacity-Effect.o effects/audacity-EffectCategory.o effects/audacity-EffectManager.o effects/audacity-Equalization.o effects/audacity-Equalization48x.o effects/audacity-Fade.o effects/audacity-FindClipping.o effects/audacity-Generator.o effects/audacity-Invert.o effects/audacity-Leveller.o effects/audacity-LoadEffects.o effects/audacity-Noise.o effects/audacity-NoiseRemoval.o effects/audacity-Normalize.o effects/audacity-Paulstretch.o effects/audacity-Phaser.o effects/audacity-Repair.o effects/audacity-Repeat.o effects/audacity-Reverb.o effects/audacity-Reverse.o effects/audacity-SBSMSEffect.o effects/audacity-ScienFilter.o effects/audacity-Silence.o effects/audacity-SimpleMono.o effects/audacity-SoundTouchEffect.o effects/audacity-StereoToMono.o effects/audacity-TimeScale.o effects/audacity-TimeWarper.o effects/audacity-ToneGen.o effects/audacity-TruncSilence.o effects/audacity-TwoPassSimpleMono.o effects/audacity-Wahwah.o export/audacity-Export.o export/audacity-ExportCL.o export/audacity-ExportFLAC.o export/audacity-ExportMP2.o export/audacity-ExportMP3.o export/audacity-ExportMultiple.o export/audacity-ExportOGG.o export/audacity-ExportPCM.o import/audacity-Import.o import/audacity-ImportFLAC.o import/audacity-ImportLOF.o import/audacity-ImportMP3.o import/audacity-ImportOGG.o import/audacity-ImportPCM.o import/audacity-ImportRaw.o import/audacity-RawAudioGuess.o import/audacity-FormatClassifier.o import/audacity-MultiFormatReader.o import/audacity-SpecPowerMeter.o ondemand/audacity-ODComputeSummaryTask.o ondemand/audacity-ODDecodeFFmpegTask.o ondemand/audacity-ODDecodeTask.o ondemand/audacity-ODManager.o ondemand/audacity-ODTask.o ondemand/audacity-ODTaskThread.o ondemand/audacity-ODWaveTrackTaskQueue.o prefs/audacity-BatchPrefs.o prefs/audacity-DevicePrefs.o prefs/audacity-DirectoriesPrefs.o prefs/audacity-EffectsPrefs.o prefs/audacity-ExtImportPrefs.o prefs/audacity-GUIPrefs.o prefs/audacity-ImportExportPrefs.o prefs/audacity-KeyConfigPrefs.o prefs/audacity-LibraryPrefs.o prefs/audacity-MidiIOPrefs.o prefs/audacity-ModulePrefs.o prefs/audacity-MousePrefs.o prefs/audacity-PlaybackPrefs.o prefs/audacity-PrefsDialog.o prefs/audacity-ProjectsPrefs.o prefs/audacity-QualityPrefs.o prefs/audacity-RecordingPrefs.o prefs/audacity-SpectrumPrefs.o prefs/audacity-ThemePrefs.o prefs/audacity-TracksPrefs.o prefs/audacity-WarningsPrefs.o toolbars/audacity-ControlToolBar.o toolbars/audacity-DeviceToolBar.o toolbars/audacity-EditToolBar.o toolbars/audacity-MeterToolBar.o toolbars/audacity-MixerToolBar.o toolbars/audacity-SelectionBar.o toolbars/audacity-ToolBar.o toolbars/audacity-ToolDock.o toolbars/audacity-ToolManager.o toolbars/audacity-ToolsToolBar.o toolbars/audacity-TranscriptionToolBar.o widgets/audacity-AButton.o widgets/audacity-ASlider.o widgets/audacity-AttachableScrollBar.o widgets/audacity-ErrorDialog.o widgets/audacity-ExpandingToolBar.o widgets/audacity-FileHistory.o widgets/audacity-Grabber.o widgets/audacity-Grid.o widgets/audacity-HelpSystem.o widgets/audacity-HtmlWindow.o widgets/audacity-ImageRoll.o widgets/audacity-KeyView.o widgets/audacity-LinkingHtmlWindow.o widgets/audacity-Meter.o widgets/audacity-MultiDialog.o widgets/audacity-numformatter.o widgets/audacity-ProgressDialog.o widgets/audacity-Ruler.o widgets/audacity-TimeTextCtrl.o widgets/audacity-valnum.o widgets/audacity-Warning.o xml/audacity-XMLFileReader.o xml/audacity-XMLWriter.o export/audacity-ExportFFmpeg.o export/audacity-ExportFFmpegDialogs.o import/audacity-ImportFFmpeg.o effects/ladspa/audacity-LadspaEffect.o effects/ladspa/audacity-LoadLadspa.o ondemand/audacity-ODDecodeFlacTask.o effects/nyquist/audacity-LoadNyquist.o effects/nyquist/audacity-Nyquist.o effects/lv2/audacity-LoadLV2.o effects/lv2/audacity-LV2Effect.o effects/lv2/audacity-LV2PortGroup.o audacity-NoteTrack.o import/audacity-ImportMIDI.o effects/vamp/audacity-LoadVamp.o effects/vamp/audacity-VampEffect.o effects/VST/audacity-VSTEffect.o  -L/opt/local/lib /opt/local/lib/libexpat.dylib ../lib-src/FileDialog/.libs/libFileDialog.a /opt/local/lib/libportaudio.dylib ../lib-src/portmixer/src/.libs/libportmixer.a /opt/local/lib/libsndfile.dylib ../lib-src/lib-widget-extra/.libs/libwidgetextra.a -L/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib -lwx_osx_cocoau_xrc-3.0 -lwx_osx_cocoau_webview-3.0 -lwx_osx_cocoau_html-3.0 -lwx_osx_cocoau_qa-3.0 -lwx_osx_cocoau_adv-3.0 -lwx_osx_cocoau_core-3.0 -lwx_baseu_xml-3.0 -lwx_baseu_net-3.0 -lwx_baseu-3.0 /opt/local/lib/libFLAC.dylib /opt/local/lib/libFLAC++.dylib /opt/local/lib/libid3tag.dylib /opt/local/lib/libmad.dylib ../lib-src/libnyquist/libnyquist.a /opt/local/lib/libSoundTouch.dylib ../lib-src/libsoxr/src/libsoxr.a /opt/local/lib/libtwolame.dylib -lmx -lm /opt/local/lib/libvorbisenc.dylib /opt/local/lib/libvorbisfile.dylib /opt/local/lib/libvorbis.dylib /opt/local/lib/libogg.dylib ../lib-src/lv2/liblv2.a ../lib-src/portsmf/libportSMF.a ../lib-src/sbsms/src/.libs/libsbsms.a ../lib-src/libvamp/libvamp-hostsdk.a -lz -framework OpenGL -framework System -framework Cocoa -framework IOKit -framework Carbon -framework AudioUnit -framework AudioToolbox -framework CoreAudio
clang: warning: argument unused during compilation: '-rdynamic'
Undefined symbols for architecture x86_64:
  "_ifft8pt", referenced from:
      _iffts1 in libnyquist.a(fftlib.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [audacity] Error 1

[mojca (Mojca Miklavec)]

• ​http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2012-December/245884.html
• ​https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=174376
• ​http://permalink.gmane.org/gmane.comp.audio.audacity.devel/26765

This worked for me:

lib-src/libnyquist/nyquist/ffts/src/fftlib.c

@@ -1347 +1347 @@
 ioptr[7] = scale*f3i;
 }
 
-inline void ifft8pt(float *ioptr, float scale);
-inline void ifft8pt(float *ioptr, float scale){
+static inline void ifft8pt(float *ioptr, float scale);
+static inline void ifft8pt(float *ioptr, float scale){
 /***   RADIX 8 ifft     ***/
 float w0r = 1.0/MYROOT2; /* cos(pi/4)   */
 float f0r, f0i, f1r, f1i, f2r, f2i, f3r, f3i;

[mojca (Mojca Miklavec)]

So after switching to python27 (this needs to be fixed somehow) and applying the above patch, I was able to build and run audacity with wxWidgets-3.0. It had some hiccups like this though:

../src/osx/cocoa/evtloop.mm(131): assert "m_modalNestedLevel == 0" failed in ~wxGUIEventLoop().

Call stack:
[00] wxEventLoop::~wxEventLoop()             
[01] wxAppConsoleBase::MainLoop()            
[02] wxApp::OnRun()                          
[03] wxEntry(int&, wchar_t**)                
[04] main                                    
[05] start                                   
[06] 0x00000001                              

Do you want to stop the program?
You can also choose [Cancel] to suppress further warnings.

We should find a way to make an app by default. Maybe there's something already "built-in" that makes the app automatically (by providing a different target to make). Else we could use the app PortGroup to create one.

[RJVB (René Bertin)]

Replying to mojca@…:

-inline void ifft8pt(float *ioptr, float scale);
-inline void ifft8pt(float *ioptr, float scale){
+static inline void ifft8pt(float *ioptr, float scale);
+static inline void ifft8pt(float *ioptr, float scale){

That's part of the patches. In my original port I had simply removed the inline keyword, the Debian patches include the one you found too. Weird. Did you perhaps use the merged Portfile (with a patchfile dropped during the merge)?

As to Python: checking on Linux showed that it must be a 2.7 version. I ran 2to3 on the waflib directory, which completed without failures as far as I could tell, but the resulting code raised errors. Python is only used for building anyway.

I also get the assertion dialogs. Somehow Audacity thinks it's been built as a debug build. Maybe something the Debian patches arrange for. Anyway, I should have mentioned that as another reason why I don't want to spend time getting this to work "just right"

Making an app bundle shouldn't be too hard. IIRC wx even has a script to do that, but if that fails it's not a big deal to create one in the post-destroot. Or with the app PortGroup (I presume its documentation is "inline"?)

[mojca (Mojca Miklavec)]

Replying to rjvbertin@…:

Replying to mojca@…:

-inline void ifft8pt(float *ioptr, float scale);
-inline void ifft8pt(float *ioptr, float scale){
+static inline void ifft8pt(float *ioptr, float scale);
+static inline void ifft8pt(float *ioptr, float scale){

That's part of the patches.

No, it's not. You have patched rifft8pt, but not ifft8pt.

Did you perhaps use the merged Portfile (with a patchfile dropped during the merge)?

Yes, I used the merged Portfile, but I don't find the patch for that in clang-ftbfs.patch.

I also get the assertion dialogs. Somehow Audacity thinks it's been built as a debug build.

I think it's wxWidgets that's showing those errors.

Making an app bundle shouldn't be too hard. IIRC wx even has a script to do that, but if that fails it's not a big deal to create one in the post-destroot. Or with the app PortGroup (I presume its documentation is "inline"?)

I can help you with using the app PortGroup, but you basically need just three lines: app name, link to binary and icon.

[RJVB (René Bertin)]

Replying to mojca@…:

No, it's not. You have patched rifft8pt, but not ifft8pt.

Then I have no idea how things could compile on my end (and on Bradley's VM, and under Debian/Ubuntu), or why this fails on your end.

I also get the assertion dialogs. Somehow Audacity thinks it's been built as a debug build.

I think it's wxWidgets that's showing those errors.

Yes, but usually "release" builds don't include assertions, right? Actually, maybe that means that port:wxWidgets is built in debug mode?

I can help you with using the app PortGroup, but you basically need just three lines: app name, link to binary and icon.

OK. I'll look at the python and ifft8pt issues now, but the merging will have to wait till next week.

[mojca (Mojca Miklavec)]

Replying to rjvbertin@…:

Replying to mojca@…:

No, it's not. You have patched rifft8pt, but not ifft8pt.

Then I have no idea how things could compile on my end (and on Bradley's VM, and under Debian/Ubuntu), or why this fails on your end.

Neither do I. (It might have to do with different version of clang or maybe some libraries are compiled here that aren't on your machine, but that's pure speculation.)

I also get the assertion dialogs. Somehow Audacity thinks it's been built as a debug build.

I think it's wxWidgets that's showing those errors.

maybe that means that port:wxWidgets is built in debug mode?

That's what I was trying to suggest. See ​http://docs.wxwidgets.org/3.0/group__group__funcmacro__debug.html. I never looked into details though. But those messages are usually helpful, in particular during transition from 2.8 to 3.0.

OK. I'll look at the python and ifft8pt issues now, but the merging will have to wait till next week.

I've done the merging already, so you would only need to review it. You can take a look at (temporary address) ​https://github.com/mojca/macports-by-rjvb/tree/master/audio/audacity-devel. I also fixed some other minor issues there.

[mojca (Mojca Miklavec)]

Also, Audacity version 2.1.0 is out.

[mojca (Mojca Miklavec)]

I see your new patches for python, but I see that you only patched two files. While I was still on python34 the list of files to patch was long:

• lib-src/lv2/lv2/waflib/Build.py
• lib-src/lv2/lv2/waflib/Configure.py
• lib-src/lv2/lv2/waflib/Context.py
• lib-src/lv2/lv2/waflib/Node.py
• lib-src/lv2/lv2/waflib/Scripting.py
• lib-src/lv2/lv2/waflib/Utils.py

and that wasn't nearly enough (I gave up after that and switched to 2.7).

I have one more suggestion for later (once you get close to the state when it's ready to be released). It would be nice to run autoreconf locally and provide a patch for configure file(s). But I don't know if doing that is feasible. It's just a suggestion. Usually I provide a patch for configure files, but usually that's small enough.

About other patches:

-   #ifdef __WXMAC__
+   #if defined(__WXMAC__) || defined(__APPLE__)

Why do you need to check for __WXMAC__? Wouldn't just #ifdef __APPLE__ be enough?

include_wxmac_code_in_wxgtk.diff: just replace #ifdef __WXMAC__ with #ifdef __APPLE__

[mojca (Mojca Miklavec)]

About wxWidgets versions/variants: I would suggest to provide a single port with two experimental variants. There is no need for a separate devel/experimental port.

Then just make sure that your favourite variant works as expected (that would probably be wxgtk28) and gets selected by default. You don't need to worry about 100% proper functionality of the variant wxwidgets30/wxgtk30. Just put them there and you might find someone willing to investigate the remaining problems.

[RJVB (René Bertin)]

Replying to mojca@…:

Also, Audacity version 2.1.0 is out.

Also, damn! :)

I see your new patches for python, but I see that you only patched two files.

Yes. That's because I made sure they invoked an appropriate python interpreter, so that we don't have to patch all the script files. As I said, I processed the whole waflib with 2to3 (from port:python3.4) but that only takes care of the syntax (which apparently isn't enough).

It would be nice to run autoreconf locally and provide a patch for configure file(s).

I could try to see how big that patchfile is going to be ... I did try to run autoreconf selectively, but there too I gave up at some point and just let it run recursively through all directories. Which results in *lots* of changed files.

Actually, I'm not so sure if it's really feasible. There are a few reinplace commands in the post-patch, and some of those are to patch in the actual $prefix. Those are done before the autoreconf, so your suggestion might not be feasible. If anything it's not going to be straightforward. It's annoying the autoreconf step takes so long, but then it is only required for the wx* 3.0 version. For the wxgtk 2.8 variant I patched both the autoconf/automake files and their products.

[RJVB (René Bertin)]

I had some time to have a look at v2.1.0 .

As could be expected, that release breaks the wxWidgets 3.0 patches in a big way. So what I'll be doing is

• create an updated patchset for v2.1.0/wxGTk 2.8 and get that to build. I'll be using my initial port for that
• wait a bit to see if Debian or Ubuntu update their v3.0 patches quickly so I can create a merged audacity-devel port for v2.1.0
• if that takes too long, we'll have to discuss whether it'd be OK to have a merged file that supports 2 versions. Patchfile management will become a bit more interesting in that case ...

[RJVB (René Bertin)]

Audacity v2.1.0 is now available through ​https://github.com/RJVB/mp-port-repository/tree/master/audio/audacity . Now we'll wait and see if and how quickly the wxWidgets 3.0 patch is updated ...

[mojca (Mojca Miklavec)]

What do you mean with "Now we'll wait and see if and how quickly the wxWidgets 3.0 patch is updated"? (I could try to see if some patches could be auto-updated.)

I only see a three-days-old commit with "version 2.0.6".

[RJVB (René Bertin)]

From my comment #30: "wait a bit to see if Debian or Ubuntu update their v3.0 patches [...]"

I've updated a number of the patches for 2.1.0 using [d]quilt, but the wxX 3.0 patch simply doesn't apply. There have been lots of changes to the Audacity code (which made it hard enough to re-do certain of my own patches), and in their own words, the wxW 3.0 version by Debian is unstable. So it'll be best to leave the updating of that patch to the same people who authored it.

[RJVB (René Bertin)]

Well, it's taken a while, but I've made some progress on a "native" Audacity, thanks to progress by the Audacity team.

I even got it to build in 64bit mode.

The build system doesn't provide a way to create an app bundle; it seems I'll have to "retrofit" the app bundle skeleton around the regular executable. Until then, audacity "native" lives in port:audacity-devel, which can be found here: ​https://github.com/RJVB/macstrop/tree/master/audio/audacity-devel

[RJVB (René Bertin)]

​https://github.com/RJVB/macstrop/tree/master/audio/audacity

My port now creates a functional (though not standalone) app bundle and resolves a few other minor issues. I've thus renamed it to port:audacity, and will be attaching the files.

For reference and those who might have use running audacity remotely over X11: the wxGTK-based previous version is now available at ​https://github.com/RJVB/macstrop/tree/master/audio/audacity-gtk .

[RJVB (René Bertin)]

All patchfiles not refreshed are no longer used; the current list according to .macports.audacity.state is

patch: fix-minsrc-autoreconf.patch
patch: workaround-wxwidgets-fit-recovery.patch
patch: add_missing_newline.diff
patch: libvamp-Makefile-for-osx.diff
patch: src-Makefile-for-osx.diff
patch: FFMpegh_build_against_ffmpeg.diff
patch: portaudio-no-universal-build.diff
patch: buildinfo-clarify-no-gstreamer.diff
patch: add_enGB_translation.diff
patch: patch-avoid-clang-choke-on-confbase.diff
patch: patch-waf-use-python27.diff
patch: patch-no-rtld_deepbind.diff
patch: patch-more-decent-font-sizes.diff
patch: patch-vstcontrolosx.diff
patch: patch-libnyquist-symbol-visibility.diff
patch: patch-fix-audiounits.diff

Note that I found a few glitches in the en_GB translation so I'll probably be pushing another update.

[mojca (Mojca Miklavec)]

Replying to rjvbertin@…:

For reference and those who might have use running audacity remotely over X11: the wxGTK-based previous version is now available at ​https://github.com/RJVB/macstrop/tree/master/audio/audacity-gtk .

I didn't check the contents or differences between the two ports you refer to, but if you believe that there is real demand for it, it might be feasible to create a variant with almost the only difference that you would use "wxWidgets.use wxGTK-3.0" (but probably a few more dependencies & patches would be needed). If I was the maintainer, I wouldn't bother about support for wxGTK though.

[RJVB (René Bertin)]

No, I won't bother with official support either, which is why I didn't make the GTk version a subport and didn't update the wxGTK version to 2.1.2 too.

[RJVB (René Bertin)]

fixes regression

[RJVB (René Bertin)]

Translations now made visible to the application, not just my own en_GB translation.

[mojca (Mojca Miklavec)]

The installation fails for me because I used "port select python python3.5":

Traceback (most recent call last):
  File "waf", line 162, in <module>
    from waflib import Scripting
  File "/path/to/audacity/work/Audacity-2.1.2/lib-src/lv2/lv2/waflib/Scripting.py", line 88
    except Errors.WafError ,e:
                           ^
SyntaxError: invalid syntax
configure: error: ./configure failed for lib-src/lv2

You need some more aggressive patching of python scripts and note that the following doesn't work:

lib-src/lv2/lv2/waf

@@ -1 @@
-#!/usr/bin/env python
+#!/opt/local/bin/python2.7
 # encoding: ISO8859-1
 # Thomas Nagy, 2005-2012

You should use ${prefix} rather than hardcoding "/opt/local". You should remove patch-waf-use-python27.diff and use something like the following inside post-patch:

# or ${prefix}/bin/python2.7
set python_bin ${frameworks_dir}/Python.framework/Versions/2.7/bin/python2.7
# Ensure usage of python27
# (insteaf of the currently active python)
fs-traverse f ${worksrcpath} {
    if {[string match "*.py" "$f"]} {
        reinplace "s|/usr/bin/env python|${python_bin}|" $f
    }
}

The next problem lies in lib-src/lv2/configure and lib-src/lv2/build:

$(which python python2 | tail -1) waf --prefix="." --include="." $@ configure || exit 1

and potentially elsewhere as well. You should report at least that last problem upstream. They should respect something like "export PYTHON=/weird/path/to/python" or "./configure ... PYTHON=/weird/path/to/python"

[mojca (Mojca Miklavec)]

There is no audacity.sh is files and the post-destroot phase trying to execute

# install a wrapper script in ${prefix}/bin
xinstall -m 755 ${filespath}/audacity.sh ${destroot}${prefix}/bin/audacity
reinplace "s|@AUD_APP_PATH@|${aud_app_path}|g" ${destroot}${prefix}/bin/audacity

fails:

Error: org.macports.destroot for port audacity returned: xinstall: Cannot stat: /path/to/dports/audio/audacity/files/audacity.sh, No such file or directory

After fixing the problems with Python and commenting out those two lines that were supposed to install ${prefix}/bin/audacity, the build runs fine for me and the applications seems to work. I didn't do any heavy testing though (other than some very trivial tasks like voice recording).

[RJVB (René Bertin)]

I'm a bit surprised that I let hardcoded paths get through and that I apparently forgot to include the wrapper script ... :-/

As to testing on your end: there's a logging feature under the help menu. Any blatant issues with your build/install should show up in there.

[mojca (Mojca Miklavec)]

I'm sorry, I later realized that you replace /opt/local in post-patch, so that part is not problematic (it's just that usually ports use something like @@PREFIX@@ and I was confused/didn't double-check).

I also didn't double-check the python scripts. I now realized that no python script gets installed, so maybe patching configure and build inside lv2 to make sure that proper version of python is called might be enough.

(In theory you could also just symlink audacity binary without a wrapper or not provide any command-line tool at all. In case of a symlink there would be no proper icon in dock etc., but it would work.)

[RJVB (René Bertin)]

Heh, yeah, I often do that because /opt/local is as good a replacement pattern as @@PREFIX@@ or whatever, and at least I know I won't forget to hand-edit a patch if ever I regenerate it from a git diff or something of the sort. :)

And you're right, the reason I didn't give the python issue more attention is that the scripts are only used during the build. I'd have pointed that out if weren't really occupied with a number of other things right now.

As to the wrapper: a symlink could do but as you noticed it means "no icon in the Dock etc.". Writing a wrapper script isn't hard, I just pushed the file to my repo.

[mojca (Mojca Miklavec)]

So should I simply patch the "python thing" (most likely just the two scripts) and commit the port to the MacPorts repository?

It seems to me that the repo contains more patches than you actually use, so I would just include those that are needed. Does that sound OK?

As far as the script goes: what's the advantage of "exec" with respect to something like "open -n /Applications/MacPorts/Audacity.app --args $@" ? In the second case the app is "non blocking" (but it also doesn't print anything to the terminal, so --help and -v won't return anything useful).

[RJVB (René Bertin)]

How do you propose to patch the 2 "python thing" scripts? Something that involves supporting python3 too? Ideally the port wouldn't require anyone to install a specific python version (when building from source) but that would require invoking the 2to3 converter when necessary. As far as I can see the build system just needs a python 2 interpreter, not even any specific packages. Can't we just use the system python in that kind of scenario?

The wrapper script: I don't really see the point in using open here. Someone who starts audacity from the terminal only to avoid having to dig out the app icon and click on it can just as well type open [-n] -a audacity instead of simply audacity. The added value is in the terminal output you can obtain. The exec is of course optional, it just means you don't end up with an unnecessary sleeping shell process.

[mojca (Mojca Miklavec)]

No, there is no point in making conversion to Python 3. We just need to make sure that we don't execute "which python" which could be python 3 (as was in my case).

[RJVB (René Bertin)]

Ah, ok, so that's indeed what you meant, I wasn't sure about that.

What about the idea of not adding a python dependency at all, supposing the system python is sufficient?

[mojca (Mojca Miklavec)]

We could do that as well, but we might have to check which versions of python are available on different OS-es then. (I now fixed that problem with python and made some other minor changes.)

I now have a commit ready, but I wanted to do the final build just to make sure that everything is still working as expected.

My suggestion would be to commit the port as-is now. I'm almost sure that there will be a number of unexpected issues, but we'll get more feedback and we'll have more time to discuss further improvements. In particular I would like to submit as many patches as possible upstream to minimize the burden of maintainance in the future, but it makes no sense to wait until all the problem are fixed, let's just get the port in the wild. I would postpone switching to system python until we do some more testing. I can hardly imagine any MacPorts user that doesn't end up with a dependency on Python (sooner or later) and in case that we are lucky with the licence and get a binary build (I didn't check that yet), users won't even need to install Python.

[mojca (Mojca Miklavec)]

I committed r146082.

But feel free to open another ticket(s) for further improvements.

Regarding wxGTK: it would probably be helpful to get it working (again?) for the sake of sanitizing different patches before submitting patches upstream. I'm not saying that we necessarily need an official port in MacPorts, but we need to know what patches are needed for what platform.

[mojca (Mojca Miklavec)]

Binary distributability introduced in r146086.

The website says "either version 2 of the License, or (at your option) any later version", so the licence is GPL-2+ rather than GPL-2 (that make a huge difference because GPL-2 is apparently incompatible with GPL-3[+]; who would understand). The only conflict that was left was with openssl which is a dependency of curl and curl is a dependency of cmake (which is only used for building some modules, so it shouldn't conflict).

The port was successfully built on all the (available) buildbots.