Frank & RestKit (or other static libs)

[Matt Brooke-Smith]

Hi,

I'm having issues with the new frank build command. I've got the RestKit library embedded in my project as a dependency, but when I run 'frank build' I get the following stacktrace:-

=== BUILD NATIVE TARGET RestKit OF PROJECT RestKit WITH CONFIGURATION Debug ===

Check dependencies

2012-07-11 00:07:51.250 xcodebuild[6509:3a03] ASSERTION FAILURE in /SourceCache/IDEXcode3ProjectSupport/IDEXcode3ProjectSupport-1198/Xcode3Sources/XcodeIDE/Frameworks/DevToolsBase/pbxcore/NativeBuildSystem/XCDependencyNode.m:517

Details:  command should be an instance inheriting from XCDependencyCommand, but it is nil

Object:   <XCDependencyNode: 0x4014b4820>

Method:   -addDependedNode:

Thread:   <NSThread: 0x40080fd20>{name = (null), num = 3}

Backtrace:

  0  0x0000000102a49c8f -[PBXTargetBuildContext(DependencyGraphEvents) handleFailureInMethod:object:fileName:lineNumber:messageFormat:arguments:] (in DevToolsCore)

  1  0x0000000101c575d5 _DVTAssertionFailureHandler (in DVTFoundation)

  2  0x0000000102ad1b91 -[XCDependencyNode addDependedNode:] (in DevToolsCore)

  3  0x0000000102b2a042 -[XCSourcesBuildPhaseDGSnapshot(DependencyGraphCreation) computeDependenciesInTargetBuildContext:] (in DevToolsCore)

  4  0x0000000102a9511e -[XCProductTypeSpecification computeDependenciesInTargetBuildContext:] (in DevToolsCore)

  5  0x0000000102b164d3 -[XCNativeTargetDGSnapshot(DependencyGraphCreation) computeDependenciesInTargetBuildContext:] (in DevToolsCore)

  6  0x0000000102a38f81 -[PBXTargetBuildContext createDependencyGraphWithTargetDGSnapshot:] (in DevToolsCore)

  7  0x0000000102a4ac15 -[PBXTargetBuildContext(DependencyGraphEvents) dg_setTargetSnapshot:] (in DevToolsCore)

  8  0x00007fff8a368efc __invoking___ (in CoreFoundation)

..etc etc

I've put a simple sample project here:-

https://dl.dropbox.com/u/1527100/Frank-Test.zip

Anybody got an idea on how to fix?

Thanks

Matt

[Mark Aufflick]

I'm seeing the same thing with my sub-projects, and xcodebuild by itself would fail. I can make xcodebuild work fine by switching to a Workspace rather than a raw project with sub-projects, but now I can't figure out how to tell frank to pass the -workspace and -scheme arguments to xcodebuild.

[Peter Hodgson]

Ah this is really helpful info, thanks Mark. 

We can easily add some stuff to that `frank build` command such that it takes workspace, scheme and target arguments and passes them through to xcodebuild. Anyone interested in learning how awesome the thor gem is by doing this and sending me a pull request? ;)

Cheers,

Pete

[Peter Hodgson]

Fun things, these XCode bugs.

So, the first confusing issue was that the Test project was configured with a target dependency on RestKitTests, rather than RestKit. Once I fixed that, I still got the exception though. So I did some playing around, and got to the point where

 

`xcodebuild build WRAPPER_NAME=Frankified.app` bombs with the XCode exception but `xcodebuild build` doesn't. 

So it seemed that WRAPPER_NAME was causing the issue. No idea why. The reason I set WRAPPER_NAME is so the Frankified app bundle has a well-known name that I can then reference in the `frank launch` command. Looking at the xcode build setting docs it seems that setting PRODUCT_NAME to Frankified will have the same effect. I did that, and apparently it also doesn't cause this xCode crash. That makes no sense to me, and simultaneously makes me grateful I don't have to maintain the XCode codebase.

So I guess I'll update the `frank build` command to use PRODUCT_NAME, and that will at least solve this issue. 

That said, it seems that there are other issues when the thing being built has dependent targets. It looks like XCode passes any explicit build settings to the dependent targets when they are built. That looks like it's causing issues with e.g. RestKit. I don't really know enough about the apple toolchain to have a clear solution to that bit yet. If anyone else has any insights I'd love to hear them.

Cheers,

Pete

[Matt Brooke-Smith]

Pete, Mark,

Thanks for your help - sorry about the sample project pointing to the wrong lib. I was messing around to try to make headway.

I built the latest source, and had to make one further change, but am now up and running I think.

In frankify.xcconfig changed

OTHER_LDFLAGS = $(inherited) -all_load -ObjC -framework CFNetwork -lShelley -lFrank -L Frank

to:

OTHER_LDFLAGS = $(inherited) -all_load -ObjC -framework CFNetwork -lShelley -lFrank -LFrank

(removed the space!)

Matt

[Matt Brooke-Smith]

Looks like the frank objects are being bundled into the static lib files with the RestKit code. Thats causing duplicate symbols.

https://dl.dropbox.com/u/1527100/Test-2.zip

(you'll have to replace the absolute path to Frank in frankify.xcconfig - sorry, bit lazy there)

Try running this from the root:- 

nm RestKit/build/UninstalledProducts/libFrankified.a

You can see that the frank objects are mixed with the RestKit objects.

Any thoughts? I'm also not an expert on Toolchain|anything ;)

Matt

[jon]

I've looked at this a little bit and the issue is the xcconfig being passed in on the command line.  I upgraded frank to 0.9.5.pre1 and when I pass in --scheme "SCHEMENAME" it gets a little farther but then pukes when trying to find the frank libs while building restkit.

The man for xcodebuild says:

-xcconfig filename

           Load the build settings defined in filename when building all targets.  These settings will override all other settings, including set-

           tings passed individually on the command line.

So restkit is trying to link against libFrank and libShelly and is not finding them because they aren't below the RestKit project in the directory tree.

[Peter Hodgson]

Actually I think it's a bit worse than that. Even settings which are passed to xcodebuild directly (not in an xcconfig file) are being applied when building all targets in the scheme. That's why the RestKit library is being built as libFrankified.a - it's grabbing PRODUCT_NAME from the xcodebuild command line args.

From a few minutes of googling I don't see an obvious solution to this, but I can't believe there isn't a way around this. If need be we can abandon the use of the xcconfig file for `frank build`, but we still need some way to pass build settings to xcodebuild which only apply to the main target being built and not to dependent targets. 

[Stewart Gleadow]

Yeah, the WRAPPER_NAME is generated from the PRODUCT_NAME and WRAPPER_EXTENSION build settings, isn't it? I've never set the WRAPPER_NAME directly.

I've definitely seen this issue when you feed in arguments to xcodebuild on the command line that they also get fed to subprojects and screw them up. I thought this only happened when you use an xcconfig file to feed in the arguments vs just listing them on the command line... but it seems it's the same for either approach.

The only other way I can think of to get around it would be to have a separate argument MY_APP_NAME variable. In the build settings or xcconfig for your main app, have PRODUCT_NAME=$(MY_APP_NAME). That way, it wont propagate to dependent projects.

You might need to do something with MY_LIBS to feed into OTHER_LD_FLAGS only for the Frank target, and any other settings. That means that while you don't have to duplicate a Frankified target, you would have to edit your target build settings.

- Stew

[Luke Redpath]

Just ran into this brick wall myself. As things stand, this issue makes it impossible to use 'frank build' with projects that use CocoaPods for dependency management.

My workspace has two projects - the app itself and the Pods project. The libPods.a product is a dependency for the app and is built first. Of course, `frank build` is trying to apply its overridden build settings when building libPods too.

Trying to rack my brains for a workaround to this...

[Peter Hodgson]

Here's my best idea so far for working around this:

- `frank setup` uses xcoder or the cocoapods project's xcodeproj gem to add some custom build settings to the target project. Specifically, it adds ${FRANKS_LD_FLAGS} to the target's LD_FLAGS settings

- `frank build` sets the linker flags it needs by setting FRANKS_LD_FLAGS when it invokes xcodebuild.

I think that would solve the issue, at the expense of having to mess with the app's xcode project. To be honest I'm quite frustrated at that - my goal was to not need to touch any non-Frank files at all. :(

Anyone see any issues with this approach?

Luke, you have some experience with CocoaPods I believe. Do you think that first step of messing with the app's xcodeproj is reasonable? Any chance it could screw things up or cause further issues?

Cheers,

Pete

[jon]

That seems reasonable and fairly non-intrusive, even if it's a by hand step, it's a marked improvement and significantly less fragile than maintaining a separate target for Frank.

Is there an issue for normal builds if FRANKS_LD_FLAGS is undefined?

-jon

[Stewart Gleadow]

Shouldn't be an issue, if the variable is undefined it'll just have no effect.

ie.
OTHER_LDFLAGS = -lmyOwnLibrary $(FRANKS_LDFLAGS) $(MY_OTHER_LDFLAGS)

should still pass on your own library flags, and just ignore the undefined Frank variable

- Stew

[Luke Redpath]

This seems reasonable. How would you deal with setting the DSTROOT and product name?

[Peter Hodgson]

I think I can get away with not using product name. The reason I was using DSTROOT is so that I have control over where the app ends up so I can then launch it easily with `frank launch`. I think there's probably other ways to do that. Or possibly I can use DSTROOT without the product name and it won't interfere with dependent targets.

[Peter Hodgson]

In case anyone on this thread missed it, I just posted to the list with news that the latest frank-cucumber pre-release gem *should* have a solution for this stuff. Please try it out and let us know if it's not working for you.

[Stewart Gleadow]

In regard to using DSTROOT and 'xcodebuild install', Jonathan Penn suggested on the newly created UIAutomation mailing list you could also override CONFIGURATION_BUILD_DIR, which would allow just using 'xcodebuild build' and avoid the strange places header files end up when doing an 'install'. Maybe that's a better solution? It does seem like the perfect use case for the 'install' action, but xcodebuild is so broken, we might have to work around again!

See discussion here https://groups.google.com/forum/?hl=en&fromgroups#!topic/uiautomation/FhL9l7RzRbQ and the example it refers to here https://github.com/jonathanpenn/AutomationExample

- Stew

[Matt Brooke-Smith]

Looking good on HEAD. Big thanks from me for the focus this issue got.

[Luke Redpath]

I'll test this out later myself and report back.

[Stewart Gleadow]

OK, so regarding xcodebuild build vs xcodebuild install, and headers going funny places, it's all coming back to me now.

In the WWDC talk on targets and schemes (or similar title), I noticed they removed the "copy headers build phase" and replaced it with just a "copy files" phase. I asked the speaker about this, and he said the copy headers build phase is really set up for Frameworks, and you can designate Public, Private, Project for each header in a static library. He said it didn't work properly when doing an 'install' or an 'archive', the exact problem I've been seeing. The normal "copy files" phase should be consistent in both places.

The only catch is that the built in "copy headers" phase is automatically wired to copy the public headers to $(DSTROOT)/$(INSTALL_PATH) when the install action is run, but if you use the normal "copy files" you have to add a second step to copy to the right place.

- Stew

[arjun kumar]

HEY GUYS,

i ve serious issue with restkit

am struck with frank build

please find the error message below

1 error generated.

CompileC build/GolfGogo.build/Debug-iphonesimulator/GolfGogo.build/Objects-normal/i386/MyLocationService.o GolfGogo/Classes/Models/MyLocationService.m normal i386 objective-c com.apple.compilers.llvm.clang.1_0.compiler

    cd /Users/aravindramalingam/cucumber/golf-ios

    setenv LANG en_US.US-ASCII

    setenv PATH "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/Users/aravindramalingam/.rvm/gems/ruby-1.9.3-p194/bin:/Users/aravindramalingam/.rvm/gems/ruby-1.9.3-p194@global/bin:/Users/aravindramalingam/.rvm/rubies/ruby-1.9.3-p194/bin:/Users/aravindramalingam/.rvm/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/git/bin"

    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x objective-c -arch i386 -fmessage-length=0 -std=gnu99 -fobjc-arc -Wno-trigraphs -fpascal-strings -O0 -Wno-missing-field-initializers -Wno-missing-prototypes -Wreturn-type -Wno-implicit-atomic-properties -Wno-receiver-is-weak -Wformat -Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function -Wno-unused-label -Wno-unused-parameter -Wunused-variable -Wunused-value -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wno-sign-compare -Wno-shorten-64-to-32 -Wpointer-sign -Wno-newline-eof -Wno-selector -Wno-strict-selector-match -Wno-undeclared-selector -Wno-deprecated-implementations -DDEBUG=1 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.1.sdk -fexceptions -fasm-blocks -Wprotocol -Wdeprecated-declarations -mmacosx-version-min=10.6 -g -Wno-sign-conversion -fobjc-abi-version=2 -fobjc-legacy-dispatch "-DIBOutlet=__attribute__((iboutlet))" "-DIBOutletCollection(ClassName)=__attribute__((iboutletcollection(ClassName)))" "-DIBAction=void)__attribute__((ibaction)" -D__IPHONE_OS_VERSION_MIN_REQUIRED=50100 -iquote /Users/aravindramalingam/cucumber/golf-ios/build/GolfGogo.build/Debug-iphonesimulator/GolfGogo.build/GolfGogo-generated-files.hmap -I/Users/aravindramalingam/cucumber/golf-ios/build/GolfGogo.build/Debug-iphonesimulator/GolfGogo.build/GolfGogo-own-target-headers.hmap -I/Users/aravindramalingam/cucumber/golf-ios/build/GolfGogo.build/Debug-iphonesimulator/GolfGogo.build/GolfGogo-all-target-headers.hmap -iquote /Users/aravindramalingam/cucumber/golf-ios/build/GolfGogo.build/Debug-iphonesimulator/GolfGogo.build/GolfGogo-project-headers.hmap -I/Users/aravindramalingam/cucumber/golf-ios/build/Debug-iphonesimulator/include -I/Users/aravindramalingam/cucumber/golf-ios/build/Debug-iphonesimulator/../../Headers -I/Users/aravindramalingam/cucumber/golf-ios/build/GolfGogo.build/Debug-iphonesimulator/GolfGogo.build/DerivedSources/i386 -I/Users/aravindramalingam/cucumber/golf-ios/build/GolfGogo.build/Debug-iphonesimulator/GolfGogo.build/DerivedSources -F/Users/aravindramalingam/cucumber/golf-ios/build/Debug-iphonesimulator -include /var/folders/mj/cshv9c09097bjkb12mg60lvr0000gn/C/com.apple.Xcode.501/SharedPrecompiledHeaders/GolfGogo-Prefix-fhcvrobzvgffdjdaxtryaqbtcucc/GolfGogo-Prefix.pch -DFRANKIFIED -MMD -MT dependencies -MF /Users/aravindramalingam/cucumber/golf-ios/build/GolfGogo.build/Debug-iphonesimulator/GolfGogo.build/Objects-normal/i386/MyLocationService.d --serialize-diagnostics /Users/aravindramalingam/cucumber/golf-ios/build/GolfGogo.build/Debug-iphonesimulator/GolfGogo.build/Objects-normal/i386/MyLocationService.dia -c /Users/aravindramalingam/cucumber/golf-ios/GolfGogo/Classes/Models/MyLocationService.m -o /Users/aravindramalingam/cucumber/golf-ios/build/GolfGogo.build/Debug-iphonesimulator/GolfGogo.build/Objects-normal/i386/MyLocationService.o

** BUILD FAILED **

The following build commands failed:

CompileC build/GolfGogo.build/Debug-iphonesimulator/GolfGogo.build/Objects-normal/i386/Amenities.o GolfGogo/Classes/Models/Amenities.m normal i386 objective-c com.apple.compilers.llvm.clang.1_0.compiler

(1 failure)

         run  mv /Users/aravindramalingam/cucumber/golf-ios/Frank/frankified_build/{*,Frankified}.app from "."

pls help me immediately