I am implementing an app which has a dependency to a command line tool.
This is because there are some presets to do.
The command line tool is responsible to create a sqlite file with all initial information needed by the app (clearly speaking: its just a tool to add some initial data to the app).
Now the problem is, that during debugging everything works fine but if I'll do a release build, some errors occur.
The first error was
target specifies product type 'com.apple.product-type.tool', but there's no such
product type for the 'iphoneos' platform"
This was because my main app had the command line tool as a target dependency.
I solved this by removing the target dependency and added the build to a run script phase:
#Build the initial setup target
xcodebuild -target InitialCoreDataSetup -sdk macosx -configuration $CONFIGURATION
#Run initializing data target to get current sqlite file
cd "$CONFIGURATION_BUILD_DIR"
cd ..
cd "$CONFIGURATION"
current_dir=$(pwd)
./InitialCoreDataSetup "$current_dir" "$SRCROOT" "$CONFIGURATION"
Now the problem is, that I get the following error:
=== BUILD NATIVE TARGET InitialCoreDataSetup OF PROJECT XY WITH CONFIGURATION AdHoc ===
Check dependencies
SDK Configuration Error: no wrapper for product type #
I have absolutely no idea how to fix this.
Any suggestions?
How do you provide your app with an initial sqlite file?
Thanks in advance for any help!
EDIT
At the moment the build phases of my app target are the following:
BTW: I finally got that working by the following line:
#Build the initial setup target
export DYLD_FRAMEWORK_PATH="$SYMROOT/Debug"
/usr/bin/env -i xcodebuild -target InitialCoreDataSetup -sdk "macosx" -configuration Debug OBJROOT="$SYMROOT/Debug" SYMROOT="$SYMROOT"
echo "$SYMROOT/Debug"
#Run initializing data target to get current sqlite file
cd "$SYMROOT/Debug"
./InitialCoreDataSetup "$SYMROOT/Debug" "$SRCROOT" "$CONFIGURATION"
The trick is to start the initialCoreDataSetup always in DEBUG mode
I would suggest letting Xcode do the build in this situation since you should be able to generate the sqllite file by using a build rule to run a script before the other build rules run.
Related
Summary
I'm trying to get a code coverage report from my project. However when I try to build and run tests, there is no CodeCoverage folder created in the derived data folder.
How am I trying to do this?
I am running xcodebuild as follows:
xcodebuild \
-workspace <some_workspace> \
-scheme <some_scheme> \
-destination <some_destination> \
-derivedDataPath <some_path> \
-enableCodeCoverage YES \
build test
What is the problem?
For my workspace/project it fails at the very end with a line:
xcodebuild: error: Failed to build workspace <some_workspace> with scheme <some_scheme>.
Reason: Could not determine bundle identifier for <some_test_target>'s TEST_HOST: "<some_path>/Build/Intermediates/CodeCoverage/Products/Debug-iphonesimulator/<some_product>.app"
At first it seemed directly linked to the TEST_HOST issue, but that's not the case here.
There is simply no CodeCoverage folder:
<some_path>/Build/Intermediates/CodeCoverage
What have I tried?
I tried the same with a clean new project, same running the same xcodebuild command, which succeeds. Within the Build/Intermediates/ folder exists the CodeCoverage folder.
However, in my own project, which is more complex, the Build/Intermediates/ folder contains a bunch of *.build folders (related to the app and the various frameworks, HockeySDK.build for example) and PrecompiledHeaders but no CodeCoverage folder.
When looking through the output of xcodebuild I never see a reference to the CodeCoverage folder for my project. However, for the test project, the first mention is at:
Write auxiliary files
/bin/mkdir -p /<some_path>/Build/Intermediates/CodeCoverage/Intermediates/<some_project>.build/Debug-iphonesimulator/<some_project>.build/Objects-normal/x86_64
For my project I see:
Write auxiliary files
/bin/mkdir -p /<some_path>/Build/Intermediates/<some_project>.build/Debug-iphonesimulator/<some_project>.build/Objects-normal/x86_64
Workaround
Something else that seemed to 'trick' it into working is to set the Host Application to None. After doing this it builds and tests, but tests fail due to the lack of host. However, this causes the CodeCoverage folder to be created, and if the Host Application is correctly set again, running the build and tests works fine, with a code coverage report produced.
You have to assure the package name is equal in all configurations. Xcode modifies it in case you are using unsupported characters. For instance Xcode replaces "-" with "_".
In all configurations, go to:
Project -> Build Settings -> Product Module
and set the exact same name without spaces.
I am trying to run tests automatically using Teamcity, but it seems that when the agent is compiling the project, it is not done correctly because when I run the command like for running test, I am getting the following error:
fatal error: 'Pushwoosh/PushNotificationManager.h' file not found
#import <Pushwoosh/PushNotificationManager.h>
[16:48:51][Step 2/2] ^
[16:48:51][Step 2/2] 1 error generated.
However, when I run manually the same commands I get no errors, but my test running. The application that I want to run was written in objective-c, and the command lines I am using are the following:
$ git clone REPOSITORY_URL (runs sucessfully)
$ pod install (runs sucessfully)
$ xctool -workspace Supermaxi.xcworkspace -scheme Supermaxi test -only FunctionalTests:TestCase000_Registration/test00_WrongEmail -sdk iphonesimulator (fails and I get the previous described error)
After being helped by I friend of mine, we found the solution to this issue in this link.
It turns out that the main problem was, as the link states, that CocoaPods uses symbolic links in it’s directory structure, and TeamCity can have trouble copying symbolic links in the VCS checkout to build agent, so I had to set the Version Control Settings of Teamcity as it is explained in the previous link.
Therefore, I have just changed the VCS checkout mode from Automatically on server to Automatically on agent (if supported by VCS roots). After that I run the agent again, and it worked properly.
I have a problem using xcodebuild to build the iOS app to custom directory.
Everything works well if I am building using command:
xcodebuild -workspace MyWorkspace.xcworkspace -scheme MyAppScheme -sdk iphoneos -configuration Release ONLY_ACTIVE_ARCH=NO
...but I would like the .app and .dSYM files to be saved in a specific directory (./build for example). So, I tried adding:
CONFIGURATION_BUILD_DIR=./build
or
OBJROOT=./build SYMROOT=./build
as a xcodebuild parameters. Then I've got this error (output comes from xctool as it's more readable, but the same error occurs when using xcodebuild):
✗ Link MyApp
(...)
ld: library not found for -lPods-MyApp-SomePodName
clang: error: linker command failed with exit code 1 (use -v to see invocation)
As I am using Cocoapods, my workspace contains app's project and "Pods" project. I tried using xcodebuild on several other projects that uses Cocoapods and I am always getting this error (SomePodName differs depending on project's dependencies) when trying to provide custom output directory. Please note, that it works without an issue when CONFIGURATION_BUILD_DIR, OBJROOT and SYMROOT parameters are skipped.
I wonder if anything changed recently, because I am pretty sure that I was able to build to custom directory using xcodebuild in the past. Currently, Travis-CI is still able to do it without an issue, but I have no luck when trying on my local machines.
Perhaps providing CONFIGURATION_BUILD_DIR, OBJROOT or SYMROOT is not the perfect way for specifying custom output directory. I am not sure if the problem is connected directly to Cocoapods, but the errors are always connected with some pod library.
Any hints will be appreciated.
My environment:
OS X 10.10.3
Xcode 6.3
xctool 0.2.3
cocoapods 0.36.3
Update: Problem solved
It looks like xcodebuild requires absolute path for CONFIGURATION_BUILD_DIR, OBJROOT and SYMROOT parameters.
Providing absolute path solved the problem:
CONFIGURATION_BUILD_DIR=/Users/me/Dev/MyApp/build
I'm writing a script to build and generate an .app file from an specific target and scheme (to work with simulator). I was using something like:
DEVELOPER_DIR=$xcode_app_path/Contents/Developer xcodebuild -sdk iphonesimulator -scheme "${SCHEME}" -target "${TARGET}" ONLY_ACTIVE_ARCH=NO CONFIGURATION_BUILD_DIR="${build_folder}" clean build
The problem is, that I need to open XCode for the code above to work, otherwise will show me a message telling me that:
xcodebuild: error: The project 'Project-name' does not contain a scheme named "${SCHEME}"
I still yet, don't understand what is XCode doing in background. But if I open the IDE and run the script, works. If I open and later close it, and run the script works. It's not working if the project hasn't been opened first with XCode ¬¬
Any suggestion would be appreaciated
If someone is facing the same experience, this is what I found out. And works.
Well, apparently when you create a new scheme through command line, by default is not "shared". So when you start to link to the folder
xcshareddata --> xcschemes
(trying to build with command line, for example) there's nothing to link with. Xcode do this automaticaly under the hood when you open your project...
The guys from CocoaPods were facing the same issue, so they created a Ruby gem that shares the scheme and place the file in his xcscheme folder:
This is the repo: https://github.com/CocoaPods/Xcodeproj
Also, thanks to this post and this post I found out how to use xcodeproj gem, and change the shared option with a script that I put downhere:
require 'xcodeproj'
xcproj = Xcodeproj::Project.open("MyProject.xcodeproj")
xcproj.recreate_user_schemes
xcproj.save
I am trying to simplify the build->archive->submit process for iOS app publishing.
We have over 50 mobile apps that have nearly identical framework, but with different artwork and configuration settings.
I normally would load each project in xcode 4.2 and build->archive->submit the usual way with the xcode GUI, but we are up over 50 apps now and this process is very tiresome any time we push out an update.
That being said, I am trying to speed up this process with using a shell function.
I did plenty of research and found that xcodebuild (See Reid's answer) should work, however the Archive option is not working as I get the following error:
unsupported build action 'archive'
So I wrote the following:
# $1 should be a date like: 2012-07-17
# $2 should be a time like: 10.31AM
# $mybase will be the current directory at the time the function was called
# so make sure to cd into the folder containing the xcode project folders first
function xcodeArchive {
mkdir ~/Library/Developer/Xcode/Archives/$1
mybase=$PWD
for x in `ls`
do
mkdir ~/Library/Developer/Xcode/Archives/$1/$x
mkdir ~/Library/Developer/Xcode/Archives/$1/$x/dSYMs
mkdir ~/Library/Developer/Xcode/Archives/$1/$x/Products
mkdir ~/Library/Developer/Xcode/Archives/$1/$x/Products/Applications
cd $mybase/$x
xcodebuild
#read -p "Press [Enter] to continue"
cd $mybase/$x
cp $x/$x-Info.plist ~/Library/Developer/Xcode/Archives/$1/$x/Info.plist
cp -r build/Release-iphoneos/$x.app.dSYM ~/Library/Developer/Xcode/Archives/$1/$x/dSYMs/$x.app.dSYM
cp -r build/Release-iphoneos/$x.app ~/Library/Developer/Xcode/Archives/$1/$x/Products/Applications/$x.app
cd ~/Library/Developer/Xcode/Archives/$1/
mv $x $x\ $1\ $2.xcarchive
cd $mybase
done
}
export -f xcodeArchive
I put this in my .bash_profile and everything runs correctly as I would expect, except I'm not copying the correct "Info.plist" and I can't figure out where to copy it from or how to generate it. So now I am stuck.
Xcode will recognize the archives, but it lists them under "Unknown Schema" and "Unnamed Archive" in the organizer.
Any help regarding now to get the correct Info.plist is greatly appreciated.
I also welcome recommendations on how to improve the script and/or a more efficient way to batch build+archive these iOS apps.
Note:
I am unable to upgrade beyond Xcode 4.2 as that requires (as I understand it) OS X 10.7+ which I am not able to obtain yet (company computer).
I am still very much a bash/shell novice, so I apologize for any ugly code/practice above.
Also, this is for official app submission, not for ad-hoc or anything like that.
Thanks again for your help.
I had the same issue with the archive command, and found this question via Google. It would fail with this build command:
xcodebuild -verbose -project $ProductName.xcodeproj -target $ProductName -configuration Release -sdk $SDK clean archive CONFIGURATION_BUILD_DIR="$PROJECT_PATH/build" PROVISIONING_PROFILE="${DIST_PROVISONING_PROFILE}"
Yet, it would succeed with this build command:
xcodebuild -verbose -project $ProductName.xcodeproj -scheme $ProductName -configuration Release -sdk $SDK clean archive CONFIGURATION_BUILD_DIR="$PROJECT_PATH/build" PROVISIONING_PROFILE="${DIST_PROVISONING_PROFILE}"
The only difference is specifying the scheme in lieu of the target to build. If there is a sensible reason for this behavior, I'd enjoy hearing it.
I'm running XCode 4.5.1 on Mac OS X 10.7.5
OK I found a solution that will work. After doing a lot more searching and a lot of guess and check, I found I can still use the "archive" option with xcodebuild, I just have to specify a workspace and scheme and apparently I wasn't doing that correctly before as it now works.
So, for anyone looking for a similar solution (to batch archive xcode projects), here is my function:
# $mybase will be the current directory at the time the function was called
# so make sure to cd into the folder containing the xcode project folders first
function xcodeArchive {
mybase=$PWD
for x in `ls`
do
cd $mybase/$x
xcodebuild -workspace $x.xcodeproj/project.xcworkspace -scheme $x archive
cd $mybase
done
}
export -f xcodeArchive