I can build my Cocoapods project using this command:
base=$(basename *.xcworkspace .xcworkspace) xcodebuild -sdk "iphonesimulator$ios_version" \
CONFIGURATION_BUILD_DIR="$build_dir/build" \
-workspace $base.xcworkspace -scheme $base -configuration AdHoc \
DSTROOT=$build_dir \
OBJROOT=$build_dir \
SYMROOT=$build_dir \
ONLY_ACTIVE_ARCH=NO \
"$@"
However, if I use this command it fails:
base=$(basename *.xcworkspace .xcworkspace) xcodebuild -sdk "iphonesimulator$ios_version" \
CONFIGURATION_BUILD_DIR="$build_dir/build" \
-workspace $base.xcworkspace -scheme $base -configuration AdHoc \
PRODUCT_NAME=app \ <============= THIS IS THE EXTRA LINE =====
DSTROOT=$build_dir \
OBJROOT=$build_dir \
SYMROOT=$build_dir \
ONLY_ACTIVE_ARCH=NO \
"$@"
And more strangely, if I use the first command and then the second command it will work. (Delete the build directory to reset.)
Are others experiencing the same issue? And is it possible to build a cocoapods project using PRODUCT_NAME and CONFIGURATION_BUILD_DIR together some other way?
I have the same problem and found the root cause about the problem.
Environment: Xcode 6.1 (6A1052c), OSX 10.10 (14A389)
The cause is the PRODUCT_NAME property not only affects built *.app but also library *.a files for CocoaPods.
I tried Dean's and Joel's solutions, but not worked for me. In my scenario, I need to build many *.app files with different product name and some little different in image resources and settings. Thus, I want to build different *.app files in a build script which I can trigger the process with just a click.
Here's what happens if we set PRODUCT_NAME in xcodebuild's options with *.xcworkspace in following command:
xcodebuild -workspace $PROJECT_NAME.xcworkspace \
-scheme $PROJECT_NAME \
-configuration Distribution \
CONFIGURATION_BUILD_DIR=$PROJECT_SRC/build \
PRODUCT_NAME=$NEW_PRODUCT_NAME build
Per Dean's solution, the problem still occurs even write PRODUCT_NAME config in *.xcconfig file.
And for Joel's solution, the PRODUCT_NAME config before the xcodebuild command does not in effect for new product name.
For Full's question:
And more strangely, if I use the first command and then the second command it will work. (Delete the build directory to reset.)
It's because of the first build already built essential *.a files of CocoaPods. Even the second time builds some $NEW_PRODUCT_NAME.a files (not used), the *.a files needed for linker step are already there for linking. That's why the second build process success.
Finally, my solution is that build the project and CocoaPods libraries separately.
Build CocoaPods libraries with following command
xcodebuild -project Pods/Pods.xcodeproj build
Build project with following command and add CocoaPods and other necessary libraries in search path (Don't forget to include all your necessary libraries)
xcodebuild -project $(TARGET_PROJ) \
-configuration Distribution \
-target $(TARGET_TAR) \
PRODUCT_NAME=$(NEW_PRODUCT_NAME) \
LIBRARY_SEARCH_PATHS="./Pods/build/Release-iphoneos $OTHER_PATH"
Build!
These are worked for me to have a one-click build script for same binary but with some different images and settings. Hope this will help someone who have the same problem.
Try creating a config file and move the PRODUCT_NAME and CONFIGURATION_BUILD_DIR variable to a xcconfig flag in your xcodebuild command.
Example of your xcconfig text file will look like this:
PRODUCT_NAME='This is my app'
CONFIGURATION_BUILD_DIR=/Users/myusername/Documents/myiosproject/build
Pass it into your xcodebuild:
xcodebuild [options and other args] -xcconfig mynewconfig.xcconfig
May want to do a clean and remove DerivedData for good measure, and perhaps try the build command a couple of times. xcodebuild command line seems to be pretty finicky.
Edit: If you can, I recommend giving xctools a shot. It has made my headache with xcodebuild go away.
I found the answer. You need to place PRODUCT_NAME=MyProductName
before the xcodebuild
command is given.
So
# This does NOT work
xcodebuild ... options ... PRODUCT_NAME=MyProductName
# This DOES work
PRODUCT_NAME=MyProductName xcodebuild ... options ...
Not sure why this second from works while the first does not. I'm speculating that the second form allows the setting to percolate more deeply down to the linker and other subcommands that xcodebuild delegates to, as a better env var setting, whereas the first does not. But that's just speculation. In any event, the second form works.
I have verified this in OS X 10.9.2 with Xcode 5.1.1.
Good luck!
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With