Audacity build question. for Ticket #47189

[Robert Chalmers]

Ok, that’s interesting. I’m getting a better picture of what’s going on with Audacity now. 

In answer to one of the questions below… 16GB
Mac mini 6.2 - 2012, Intel Core i7,2.3 GHz, Memory:16 GB. El-Capitan OSX 10.11.3 2TB Xcode 7.2.1 
2TB: Drive 0:HGST HTS721010A9E630. Upper bay. Drive 1:ST1000LM024 HN-M101MBB. Lower Bay

I have Memory Cleaner, but it’s stopped working for some reason and I haven’t had time to chase it up.

Robert



> On 27 Feb 2016, at 13:42, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> 
> On Saturday February 27 2016 12:53:37 Robert Chalmers wrote:
>> I don’t mean to mis-lead anyone. The issues I”m talking about are part of Audacity 2.1.2. Things like not being able to drag-highlight-scroll right in editing a track, and drag+highlight-dcroll left+edit only works sometimes.
> 
> You mean they also exist in the official build that can be downloaded from the Audacity homepage?
> 
> I think the team is aware of a certain number of issues, many of which may be side-effects of the significant number of changes they had to make to update to wxWidgets 3. The fact that 2.1.1 works for you suggests that the issues you're seeing are indeed related to that update.
> But from what I understand there is also an issue with memory management which means they use temporary files for about everything not involving nyquist (FFT) filters (which in itself removes some of the benefits of running 64 bits).
> 
>> There also appears to be something about it that interferes with other running apps, in this case, iBooks running at the same time over the course of about half an hour gets slower and slower to scroll, untill it gives up all together and becomes unusable. If I close down Audacity 2.1.2, and close iBooks, then open iBooks again. It starts working as it should.  Start up 2.1.2, and after half an hour there abouts - it caries - back comes the problem with iBooks.
> 
> How much RAM do you have in your system? There's something called Memory Cleaner in the App Store that can run automatic or regular attempts to retrieve unused memory.
> Either way it sounds like issues you should be reporting upstream.
> 
>> So, I’m not talking about the macports build of Audacity - the current port installed fine, and lives in the macports folder in Applications, although it does read the cfg file in the “default” location of course. Which doesn’t seem to trouble it.
> 
> Of course, it's supposed to behave just like official builds, apart from the fact that it's more tied to the install location and of course is built in a different way.
> 
>> While I’m thinking of it - does the port install session create a log file anywhere of what it does when “port installing” - I’d like to see what’s happening. I am probably wrong, but I don’t remember it actualy compiling and building the Audacity part. All the rest, but that last bit just flicked by too quickly…
> 
> You'd have noticed a build from source unless you have a really fast machine or asked for a non-default variant. So you probably got a binary build, which you can see as unpacking a tarball into /opt/local . To see what that installed you can do `port contents audacity`.
> To see what happens during the build, you can simply do `[sudo] port -v destroot audacity` (sudo is optional here). That will fetch and patch the sources, run configure, build, and then do a shadow install into `port work audacity`/destroot. A logfile is created that shows even more than what appears on the terminal during a verbose build; you can get the filename via `port logfile audacity`.
> 
>> So the reason/motivation is to “make it work” and remove that pesky hard coding so that updates to XCode and SDKs can be more easily followed and checked in the actual project.
> 
> Remember that Xcode isn't really designed to support software with lots of non-system dependencies and a build system based on autoconf. You're basically limited to creating custom, shell-script based targets in an Xcode project if you  need to be able to build 3rd party libraries like Audacity does.
> 
> Your best bet might actually be to create a cmake-based build system. From what I remember there has already been some work done on that. Cmake can create Xcode projects, and that feature has been improved considerably in recent versions.
> 
>> Whick is one thing XCode is good for, Sou can see where everything is at a glance pretty much.
> 
> Any self-respecting IDE can do the same, sometimes even from a Makefile.am . I'd have had a much harder time first adapting Audacity 2.1.x to wxGTK on Mac, and then 2.1.2 to 64 bits if I had not been able to open the full project in KDevelop.
> 
>> Does anyone know exactly what the calls are that require the 10.6 SDK? Shouldn’t it then just be a mission to update that code to the new SDK?
> 
> Exactly, no, but you can take stock of this by studying my patches to see what OS X-specific code is removed or put in conditional blocks. The Audacity team made a pretty good start making the code build against either legacy APIs or against modern ones so I didn't have to do much. At least not much more than what I had already done.
> Evidently QuickTime support is part of what gets lost when you drop 10.6 support. Sadly that is just something one has to live with.
> 
> R.

Robert Chalmers
robert at chalmers.com <mailto:robert at chalmers.com>.au  Quantum Radio: http://tinyurl.com/lwwddov
Mac mini 6.2 - 2012, Intel Core i7,2.3 GHz, Memory:16 GB. El-Capitan 10.11.  XCode 7.2.1
2TB: Drive 0:HGST HTS721010A9E630. Upper bay. Drive 1:ST1000LM024 HN-M101MBB. Lower Bay




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-users/attachments/20160227/9894c0a7/attachment.html>