error: 'release' is unavailable: not available in automatic reference counting mode

[ryandesign]

Hello, I'm the maintainer for Quicksilver in MacPorts. I'm trying to update our Quicksilver package to 1.2.0-final but it does not build:

/opt/local/var/macports/build/_Users_rschmidt_macports_dports_aqua_Quicksilver/Quicksilver/work/Quicksilver-1.2.0-final/Quicksilver/Code-QuickStepCore/QSCatalogEntry.m:92:5: error: 'release' is unavailable: not available in automatic reference counting mode
    dispatch_release(scanQueue);
    ^

That's on OS X 10.10 with Xcode 6.1.

[skurfer]

I think we can/should remove that line, but I’m curious how you’re building it. I do all the release builds from the command-line and have never run into that.

[ryandesign]

I’m curious how you’re building it.

After checking out the 1.2.0-final tag and cding into that directory, this command is being run:

/usr/bin/xcodebuild -project "Quicksilver.xcodeproj" -alltargets -configuration Release build \
OBJROOT=build/ SYMROOT=build/ MACOSX_DEPLOYMENT_TARGET=10.10 ARCHS=x86_64 \
SDKROOT="/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk" \
GCC_VERSION=com.apple.compilers.llvm.clang.1_0 CLANG_CXX_LIBRARY="libc++"

[pjrobertson]

.> this command is being run:…

I guess that you were setting the deployment target to 10.10 and using the 10.10 SDK. It’s probably something new added in that version of the SDK.
@skurfer - have you tried building against the 10.10 SDK? There’ll probably be a lot more warnings (about deprecations, most likely), but hopefully no more errors like this one!

I’ll probably upgrade to 10.10 once 10.10.1 comes out

On 21 Hyd 2014, at 02:04, Ryan Schmidt notifications@github.com wrote:

I’m curious how you’re building it.

After checking out the 1.2.0-final tag and cding into that directory, this command is being run:

/usr/bin/xcodebuild -project "Quicksilver.xcodeproj" -alltargets -configuration Release build
OBJROOT=build/ SYMROOT=build/ MACOSX_DEPLOYMENT_TARGET=10.10 ARCHS=x86_64
SDKROOT="/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk"
GCC_VERSION=com.apple.compilers.llvm.clang.1_0 CLANG_CXX_LIBRARY="libc++"
—
Reply to this email directly or view it on GitHub.

[skurfer]

I’ve built using the 10.10 SDK many times and don’t see this.

For what it’s worth @ryandesign, the commands we use to do the official builds are in a script: https://github.com/quicksilver/Quicksilver/blob/master/Quicksilver/Tools/qsrelease

Since you aren’t code signing or making a DMG, you could probably shorten that script to a single command like:

xcodebuild -configuration Release -scheme 'Quicksilver Distribution' clean build`

[skurfer]

I think it was the deployment target and not the SDK version that caused this. Anyway, should be fixed now that we’ve changed to 10.8.

[ryandesign]

I've applied d90bf93 to the 1.2.0 tag, and the build now fails with:

:info:build /opt/local/var/macports/build/_Users_rschmidt_macports_dports_aqua_Quicksilver/Quicksilver/work/Quicksilver-1.2.0-final/Quicksilver/Quicksilver Tests/Quicksilver_Tests.m:43:50: error: no known instance method for selector 'interfaceController'
:info:build     QSInterfaceController *i = [[NSApp delegate] interfaceController];
:info:build                                                  ^~~~~~~~~~~~~~~~~~~
:info:build /opt/local/var/macports/build/_Users_rschmidt_macports_dports_aqua_Quicksilver/Quicksilver/work/Quicksilver-1.2.0-final/Quicksilver/Quicksilver Tests/Quicksilver_Tests.m:73:50: error: no known instance method for selector 'interfaceController'
:info:build     QSInterfaceController *i = [[NSApp delegate] interfaceController];
:info:build                                                  ^~~~~~~~~~~~~~~~~~~
:info:build 2 errors generated.

To answer the earlier question about why we use all those arguments to xcodebuild, the answer is that they are the arguments added automatically by MacPorts for any port that builds using an Xcode project. They're each there for their own good reasons, and it would be more effort to remove them than to leave them there.

It looks like the flag that we're using that's causing the problem is -alltargets, which MacPorts adds because I did not specify a target to build. When I open the Xcode project in Xcode, it says there are 18 targets, but I don't know how to determine what those 18 targets are or which of them we should be building. I see -scheme 'Quicksilver Distribution' in your suggested flags, but I am not familiar with the concept of a "scheme" in Xcode and don't know what this does.

[pjrobertson]

This is running the tests. I have no idea why you’d want to do this for a release build of Quicksilver.

To save you (and us) any more troubles, I’d suggest using what Rob recommended in the first place:

xcodebuild -configuration Release -scheme 'Quicksilver Distribution’ build

To answer your previous question: https://developer.apple.com/library/ios/featuredarticles/XcodeConcepts/Concept-Schemes.html

On 2 Tach 2014, at 12:46, Ryan Schmidt notifications@github.com wrote:

I've applied d90bf93 to the 1.2.0 tag, and the build now fails with:

:info:build /opt/local/var/macports/build/_Users_rschmidt_macports_dports_aqua_Quicksilver/Quicksilver/work/Quicksilver-1.2.0-final/Quicksilver/Quicksilver Tests/Quicksilver_Tests.m:43:50: error: no known instance method for selector 'interfaceController'
:info:build QSInterfaceController *i = [[NSApp delegate] interfaceController];
:info:build ^~~~~~~~~~~~~~~~~~~
:info:build /opt/local/var/macports/build/_Users_rschmidt_macports_dports_aqua_Quicksilver/Quicksilver/work/Quicksilver-1.2.0-final/Quicksilver/Quicksilver Tests/Quicksilver_Tests.m:73:50: error: no known instance method for selector 'interfaceController'
:info:build QSInterfaceController *i = [[NSApp delegate] interfaceController];
:info:build ^~~~~~~~~~~~~~~~~~~
:info:build 2 errors generated.
To answer the earlier question about why we use all those arguments to xcodebuild, the answer is that they are the arguments added automatically by MacPorts for any port that builds using an Xcode project. They're each there for their own good reasons, and it would be more effort to remove them than to leave them there.

It looks like the flag that we're using that's causing the problem is -alltargets, which MacPorts adds because I did not specify a target to build. When I open the Xcode project in Xcode, it says there are 18 targets, but I don't know how to determine what those 18 targets are or which of them we should be building. I see -scheme 'Quicksilver Distribution' in your suggested flags, but I am not familiar with the concept of a "scheme" in Xcode and don't know what this does.

—
Reply to this email directly or view it on GitHub.

[skurfer]

The errors are probably the result of building all targets with no respect for dependency order.

Changing -alltargets to -target "Quicksilver Distribution" seems to work, if you have the ability to do that.

[ryandesign]

Thanks, that'll work.