I'm looking to build + run my iphone xcode project totally outside of xcode.
Currently I'm using xcodebuild to build the project - which seems to build cleanly:
https://gist.github.com/8eadfb1acca4d101624b
Unfortunately it doesn't seem to replicate the same Build as done by xcode. Rebuilding it leads to a bunch of syntax errors.
Are there other flags I should be passing xcodebuild?
Maybe you have a problem with shared precompiled headers? Like, building different versions of a project on the same machine. Try stating "clean build" (or clean install, whatever you want to do) as build actions at the end of your xcodebuild call.
Related
I am getting the following error only on Xcode 13.4.1 when I am trying to build the project.
Cycle in dependencies between targets '#aTargetName' and '#anotherTargetName'; building could produce unreliable results. This usually can be resolved by moving the target's Headers build phase before Compile Sources.
It gets solved if I "clean build folder" every time I need to run the project.
This is how the build phases are in the project:
***Update on 1/07/22:
The following line fix this:
Open Terminal and run:
defaults write com.apple.dt.XCBuild EnableSwiftBuildSystemIntegration 1
I had the same error. All the other SO questions refer to changing the order of the 'Headers' in the build phases or updating the build system to legacy.
I don't have a Headers phase so I just played around with what phases I did have. This is a daunting suggestion for anyone with more a few phases because permutations grow exponentially.
For myself here is the before (not working) and after (working) configuration.
Not Working
Working
I have no idea why one is working and the other isn't just that this change resolved my issue. I also commented out some localizing and linting scripts that aren't essential to run on release just dev/test builds. I also only got the error when arching the project - not when buildling.
I'm developing an embbeded framework for iOS. In order to make an universal fat (with simulator and device slices), I created an aggregate target with a script that uses xcodebuild and lipo commands to generate it, as many people does.
With XCode 7.x I had to add an user-defined settings with BITCODE_GENERATION_MODE=bitcode in order to enable it, but this has stop working since the last XCode 7.3 release.
I've tried everything I found in the internet like add OTHER_CFLAGS="-fembed-bitcode", but anything works as before...
I have seen this in the build log:
ENABLE_BITCODE is always NO, no matter I do.
Has anybody tried to create an universal fat framework with bitcode enabled using xcodebuild command since XCode 7.3?
I ran into a similar issue yesterday. After some investigation, the problem, that appears when running xcodebuild from a "Run Script" build phase in any Xcode target, seems related with the explicit specification of the toolchain to be used, done with the ENV variable TOOLCHAINS.
Therefore, until Apple releases a fixed version of Xcode 7.3, you can try to add the following command at the beginning of your script:
# workaround for bitcode generation problem with Xcode 7.3
unset TOOLCHAINS
This should be harmless, as this env variable is not set by default when you run xcodebuild from the command line, and this workaround works just fine in my case.
I'm facing the same issue. Just like you, BITCODE_GENERATION_MODE and OTHER_CFLAGS="-fembed-bitcode" are simply ignored, and my builds broke
I did notice that it sometimes work, and sometimes doesn't. It seems that if you build the framework (or aggreate target) for the simulator, the bitcode goes away, no matter what you have in the xcodebuild commands.
I'm using Xcode 7.3, and I have 2 targets : Static Library, and Aggregate target to make the fat framework.
What works for me when it builds a bitcode-less framework, is to:
Select the static library target (not the aggregate one), and pick "Generic iOS device"
Clean it
Select the static library target, but pick a simulator
Build it (works, even if it's instantaneous because it hasn't been cleaned)
Select the static library target, but pick "Generic iOS device" again.
Build it
Select the aggregate target for a "Generic iOS device"
Finally, build it
If this failed, start over. I sometimes need to do it two or three times before it works.
When I do that, my fat library ends up having bitcode.
You can check that your framework has bitcode support easily by running otool -arch armv7 -l <framework_path> | grep LLVM
In order to break it again, simply build the aggregate target for a simulator. The library will still be a fat one, but bitcode's gone.
Somebody surely can find a solution that works everytime, but at least it fixes the issue for me.
I certainly did not have to do that with Xcode 7.2, and I don't know how that works for pure CLI builds.
I'm trying to produce gcd a files from an iOS Xcode 4.2 (4D199) project called CocoaTouchHax on Lion and I'm having incredible trouble. I followed the steps here and I went as far as trying to build llvm/clang from source following steps here. However I continue to get this error:
Library not loaded: #executable_path/../lib/libprofile_rt.dylib
Where am I going wrong? I've tried to use the install_name_tool to fix the executable path to no avail. Am I over analyzing something? Am I missing something simple? I put this in as a "Run Script" phase prior to linking to ensure I've updated the #executable path and I use tool to examine the file after and the name is updated:
install_name_tool -id #executable_path/Users/cliff/dev/CocoaTouchHax/build/CocoaTouchHax/Build/Products/Debug-iphonesimulator/lib/libprofile_rt.dylib build/CocoaTouchHax/Build/Products/Debug-iphonesimulator/lib/libprofile_rt.dylib
What am I doing wrong? Help!
Update
Merely adding lib profile_rt.dylib crashes my test run immediately giving the following error when anything is run:
#executable_path/../lib/libprofile_rt.dylib
So I am certain that something needs to happen or something needs to be done to the lib profile_rt.dylib prior to execution.
Another Update I tried creating a sum link to
/Developer/usr/lib
under /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk/Developer/usr
Which I believe is part of the base the path forming the current working directory when test runs. (Assuming it runs from the bin folder there.) This would, in theory, complete the relative lookup path of ../lib/libprofile_rt.dylib from that base path but it didn't work. I've tried running the install_name_tool command prior to copying the dylib in place but I still get this error:
Library not loaded: #executable_path/../lib/libprofile_rt.dylib
I don't know what I'm doing wrong. I somehow did manage to get test coverage files to emit using some combination of the above but I was not paying close enough attention and cannot reproduce the occurance. I know this can work, I just need a little more help figuring out how.
Update: In Xcode 4.3.2 (4E2002), just switch on Generate Test Coverage Files and Instrument Program Flow, the build system will link libprofile_rt for you. Xcode 4.3, and later, is a standard Mac app and the /Developer folder is gone. So, skip steps 5-7 below. You will also have to create a class file to workaround a bug in Apple's unix implementation as described here. You'll want it in the project under test.
For Xcode 4.2 (4C199) in Snow Leopard:
Create a project, say MyProduct. Check Include Unit Tests.
Once Xcode does its thing and loads the new project, you should have two targets, MyProduct and MyProductTests. Duplicate the MyProduct target.
Select the MyProduct copy target.
Go to Build Settings. Under Code Generation turn on Generate Test Coverage Files and Instrument Program Flow.
Go to Build Phases. Expand Link Binary With Libraries. Click the +. Click Add Other.... Browse to /Developer/usr/lib. Choose libprofile_rt.dylib.
Select the MyProductTests target.
Repeat steps 4 and 5 for that target.
Go to Build Settings again. Find Bundle Loader under Linking. Change the path to the MyProduct copy app. Something like $(BUILT_PRODUCTS_DIR)/MyProduct copy.app/MyProduct copy.
Change your schemes so that the tests run under the MyProduct copy scheme and not MyProduct. If you're compiling clang on your own, you can figure out the details here.
That should work. Step 8 took me hours to figure out, it's the key. If you only see gcda files in the test build directory, that's the likely issue.
On Lion you can symlink the dylib into /usr/lib to avoid that error
sudo ln -s /Developer/usr/lib/libprofile_rt.dylib /usr/lib/libprofile_rt.dylib
I cant guarantee that that wont bust something the future however. Remember that you have done it.
Create a new configuration called "Coverage" (or whatever).
In the Coverage config variant you have created go to Build Settings and...
Add -fprofile-arcs and -ftest-coverage to Other C Flags
Switch on Generate Test Coverage Files
Switch on Instrument Program Flow
In Other Linker flags add -lprofile_rt
The reason to do it this way with a config is that you can keep your normal build untouched. Also only works on Simulator. So dont try running this on device.
And from http://mattrajca.com/post/8749868513/llvm-code-coverage-and-xcode-4
Finally, open up the Intermediates/$TARGET.build/$CONFIG/$TARGET.build/Objects-normal/$ARCH subfolder. Inside, you’ll find the aforementioned gcda and gcov files
You can open that folder with CoverStory.
Note that coverage is not cumulative (unlike Coverity) so each run starts afresh. There might be a way to change that.
I am setting up my iphone project to run with hudson, my build script works fine locally, but when executing the following command on my snow leopard server mac
xcodebuild -sdk iphoneos4.3 -workspace Moments.xcworkspace/ -scheme Moments -configuration DistributionTest
I get the following error messages.
Build settings from command line:
SDKROOT = iphoneos4.3
2011-05-11 10:32:17.729 xcodebuild[4151:903] WARNING: Timed out waiting for /"runContextManager.runContexts" (10.010780 seconds elapsed)
xcodebuild: error: The workspace 'Moments.xcworkspace/' does not contain a scheme named 'Moments'.
What's the timeout about?! And why can't it find the scheme named Moments when it's definitly there. If I open the workspace in xcode on the build server, I can see the scheme.
checking the "shared" box in the "Manage Schemes" dialog moves the schemes to Project.xcodeproj/xcshareddata/xcschemes/Scheme.xcscheme
so even if you have a clean checkout that has never been opened via the xcode ui, this will work. we use this so that buildbot can build our apps
Unfortunately xcodebuild depends on some per user files generated by the XCode. To fix this you can log in as your hudson user and run the XCode UI once. That will create the necessary files.
I'm currently trying to work around this, but copying the needed files into the source tree before building.
If you run xcodebuild and XCode is running in the background, xcodebuild will contact XCode to get the needed data. Since XCode is not running, you get the timeout.
Schemes are per default not shared between users (and your build-server). As David mentions, you can share them, but you can also just invoke the targets instead, which are shared.
So instead of
xcodebuild -scheme Foobar
it'd be
xcodebuild -target Foobar
since schemes are normally named the same as the target.
I try to automate my UI testing (using FoneMonkey ).
I have several targets, linked to different frameworks.
The issue is that I have to clean my targets before building them. If not, it looks like it loads unwanted frameworks (and thus has unexpected behavior).
So I'd like to know if there is a way to auto-clean the target(s) before building, by setting an option, using a run script...
I tried using
xcodebuild clean
But I get an
ASSERTION FAILURE in /SourceCache/DevToolsBase/DevToolsBase-1763/pbxcore/Target.subproj/PBXTarget.m:597
Any idea ?
Thanks
You can force the top level project to rebuild from scratch by removing the build directory. e.g. rm -rf build. This may be sufficient for your needs.
Otherwise, upgrade to the latest version of XCode, and failing that, submit a bug report.