I have a CI environment which builds my project. So when I compile my project with xcodebuild -target MyTarget and run it on a physical device, I get a visual bug with one of the Three20 libraries as well as a reproducible crash.
However, when I compile and run the project and the same target via Xcode I neither have the crash nor the visual problem.
Since I don't do anything fancy with xcodebuild I would expect the two builds to be identical. Generally I'd rather have the problem in two places than the two builds behave differently.
Has anyone run into similar issues and how can I make sure that the product of Xcode and xcodebuild is identical? Thanks a lot for your help.
Try running xcodebuild -scheme MyScheme, where MyScheme is most likely the name of your target if Xcode auto-generated the scheme for you.
The GUI uses schemes when building and I've found that you can usually get the same behavior by specifying a scheme to xcodebuild.
Related
Encountering following error when only building a "Universal Binary Framework" for release distribution. Same project and settings works when building "Non-Universal" scheme in debug or release mode.
Project uses Objective-C & Xcode 11 GM (11A419c). Now, updating to Xcode 11 GM Seed 2 (11A420a).
error: accessing build database "/Users/john.doe/Library/Developer/Xcode/DerivedData/FrameworkSDK-esxhqchxkdevuiapyebthsdscpje/Build/Intermediates.noindex/XCBuildData/build.db": disk I/O error
Using following build command from a script:
xcodebuild -workspace ${PROJECT_NAME}.xcworkspace -scheme ${PROJECT_NAME} -sdk iphonesimulator -configuration ${CONFIGURATION} only_active_arch=no defines_module=yes clean build CONFIGURATION_BUILD_DIR=${BUILD_DIR}/${CONFIGURATION}-iphonesimulator 2>&1
Tried a few steps: Complete clean, pod update and steps mentioned on Related error for Xcode 10 & linked post - Doesn't solve this issue
No Answer on this question:
why error "accessing build database disk I/O error"?
In case someone is still stuck here.
I follow This Answer and get rid the disk I/O error.
Adding:
OBJROOT="${OBJROOT}/DependentBuilds"
Use Command Line Tools for Xcode 11
Ensuring that correct version of Command Line Tools (xcodebuild) is used works with complete clean & building universal framework fresh. And the project is using New Build System (Default). It also worked with Xcode 11 GM - Build 11A419c (seed 1).
Use following command to ensure proper link:
xcodebuild -version
Xcode 11.0
Build version 11A419c
Earlier it was using the old Xcode10.2 xcodebuild.
Alternative workaround(s)
Not a good fix as it usages Legacy Build System instead of modern system with Xcode 11.
One option is to use Legacy Build System with Shared Project Settings when for universal framework projects.
Tried using undocumented xcodebuild parameter -UseModernBuildSystem=NO, it didn't work. [working on command line fix, will update]
Relevant release note: for GM-2 seed: Released September 16, 2019 Build 11A420a
An XCFramework makes it possible to bundle a binary framework or
library for multiple platforms —including iOS devices, iOS simulators,
and Mac Catalyst — into a single distributable .xcframework bundle
that your developers can use within their own applications. An
.xcframework bundle can be added to an Xcode target’s Link Libraries
phase and Xcode uses the right platform’s version of the included
framework or library at build time. Creation of frameworks is
supported from the command line using xcodebuild -create-xcframework.
Frameworks or libraries bundled in an XCFramework should be built with
the Build Libraries for Distribution build setting set to YES.
(49948269)
I have the same problem when building our project with XCode 14.1. I added "-derivedDataPath ../derived_data" to the build command and it build without any issue. Hope this can help.
xcodebuild -sheme YourSheme -project YourProject.xcodeproj -sdk iphoneos -configuration YourConfiguration -derivedDataPath ../derived_data clean build"
It seems that in cmd-line builds, Pods don't get built automatically. Even when invoking xcodebuild to reference the workspace that declares how projects link to each other.
Is there a way to fix this, besides manually opening the project in Xcode and building?
I don't have any problem with such configuration: CocoaPods 0.28.0 and Xcode5 (+ Command-Line Tools) here and building using the Command-Line quite often (especially for Continuous Integration) without having any problem.
Neither with the Apple's xcodebuild command, nor with xctool (see also this NSHipster's article) when building my personnal project using Travis-CI either, everything works fine;
At work we have plenty of Xcode workspaces created using CocoaPods / pod install and we use Jenkins-CI to run xcodebuild to build them and no problem either.
Maybe you need to check a bit more about your configuration? Which CocoaPods & Xcode version, Which Command-Line Tools (xcode-select --print-path?), How is you Xcode configured (maybe you changed some of Xcode's default settings that broke it somehow)?
Tell us more about your specific configuration and the error/warning messages you got, because there should not be any problem.
Also make sure you have an up-to-date version of CocoaPods (some stuff were fixed some versions ago regarding Xcode5 and the new arm64 architecture, that broke implicit dependency detection in some cases)
I'm trying to build an app using the commandline, however when I use xcodebuild -list it doesn't display the correct scheme, only those my project requires.
I have tried going into Xcode > Manage Schemes and set the correct scheme to "shared" but that doesn't help.
Using Xcode I have no problems building the main project but using Xcodebuild I can only build the dependencies.
Any help will be greatly appreciated.
EDIT:
I wonder if it is possible to make an Objective-C project (no UI, no simulator is needed, hosted on Github) to be built on Travis?
Current Travis docs seems not to contain any information regarding the option to have Objective-C projects built on Travis.
But Building a C Project says that:
Travis VMs are 32 bit and currently provide
gcc 4.6
clang 3.1
core GNU build toolchain (autotools, make), cmake, scons
and that default test script is run like
./configure && make && make test
So, to rephrase the subject question:
Do any workarounds exist to make SenTestingKit test suite, that my project currently uses, behave like a C test suite, so it could be treated as such by Travis VM?
NOTE 1: Here is the list of resources, which seem to be related to the question:
Compiling Objective-C without a GUI. It claims that Both gcc and clang compile Objective-C 2.0 and that sounds very promising!
NOTE 2: I suspect that it is possible to use some testing tool other than SenTestingKit:
this tool should be easy to be run without a GUI and without xcodebuild etc: I've opened related issue for that: Is there any non-Xcode-based command line testing tool for Objective-C?. I am even thinking about writing an easy one just to be used by my project.
A few days Travis announced that they are now also supporting objetive-c projects. See Building An Objective-C Project for more info.
Update
It is even possible to make Travis launch the simulator so that you can run application tests and UI related stuff. I required a little extra work, but it's pretty straight forward. I wrote about it here.
When I used Xcode 4.6 preview verion or xcodebuild command, I had a such error below.
invalid suffix on literal; C++11 requires a space between literal and identifier
However When I used Xcode4, there were no errors.
I don't have much knowledge about C++ and the compiler, so I couldn't find the answer from Internet.
Would you tell me how can I avoid the error with xcodebuild command?
If you invoke xcodebuild from the cmd-line, it should be essentially the same as building the target from within Xcode's IDE.
The only difference that I can think of is that running from the cmd-line will default to Release configuration, whereas inside the IDE will probably use debug. (These can be overridden in both cases).
Could it be that you have a different C++ flags for Debug and Release, and this is making it not work? Try building your project with Release mode inside the IDE, and see what happens.