Hit build and nothing gets printed in build log. What gives?
Xcode Version 8.2.1 (8C1002)
Pre-action takes place before the build, so output doesn't go to the build log, it goes to stdErr. You can copy the output to a file:
exec > ${PROJECT_DIR}/prebuild.log 2>&1
echo "hello world"
To get the environment variables to work, you also need to set "Provide build settings from" to the appropriate target.
That should write hello world to a file named "prebuild.log" in your project folder.
for XCode versions < 13.2
If you want these activities to end up in the build log, consider adding a run script to your target's build phase instead.
for XCode versions >= 13.2
The XCode build log now includes a Run pre-actions section. If you don't redirect to a file, those messages will end up as the last item in a 'Run custom shell script' in this section - access via the XCode Report Navigator.
To add to the answer, https://stackoverflow.com/a/42497746/1058199, it's important to not clutter up the project.pbxproj (where build scripts go) or your scheme file (where these scripts go) as much as possible.
With this in mind, I create a Build-Scripts folder in the project root where I put the app build scripts and pre-action scripts. This folder is dragged into the root of the project as a folder so that any script I add to it is automatically added to project.
Assuming that your pre-action script is called That_pre-action_script.sh, this is what I put in Pre-actions script based on the approved answer.
say "Pre build scripts running."
exec > "${PROJECT_DIR}/prebuild.log" 2>&1
echo "Starting build scheme Pre-actions"
"${PROJECT_DIR}/Build-Phases/That_pre-action_script.sh"
As a test, make sure to echo some message from your script so you can see it in the prebuild.log file.
Hope this helps.
And don't forget to chmod u+x your script in the terminal so that it will run.
The important part is if you can't make sure if your build script is running or not. This is where the say command us useful so that you know it's actually being issued before a build.
It's a good idea to put quotes around the path to the script in case there are any space characters (or otherwise) in the path to your project.
Related
When I build my project with Xcode 8, it saves the final build in ~/Library/Developer/Xcode/DerivedData/MyProject-[add-lots-of-random-chars-here]/Build/Products/Release-iphoneos. Is there any way to make Xcode copy the app bundle to a user-specified path after building it? e.g. how can I make Xcode copy the built app bundle to /MyBuilds after building it?
I know that I can change the path for storing derived data in my project's settings in Xcode but doing so will of course make Xcode store all data (including intermediate stuff like object code etc) in this location which I don't want. I really only want Xcode to copy the final, ready-for-distribution app bundle to a user-specified location without any intermediate files used in the build process.
How can I do that?
The solution using a script in "Build Phases" does not work properly since Xcode is not finished building the app when running the script. Here is a solution with a script that runs after all build tasks are finished:
Go to "Edit Scheme"
Click on the triangle next to "Build"
Select "Post-action"
Press the + button and select "New Run Script Option"
Select your app name in "Provide build settings from"
Add the following shell script:
Script:
PRODUCT="${BUILT_PRODUCTS_DIR}/${TARGET_NAME}.app"
cp -R "${PRODUCT}" ~/Desktop
Add a shell script to your build phases to copy the product:
Script:
PRODUCT="${BUILT_PRODUCTS_DIR}/${TARGET_NAME}.app"
cp -R "${PRODUCT}" ~/Desktop
Certainly replace ~/Desktop with a target directory of your choice.
I'm probably missing something simple here. I am trying to auto increment my build number in XCode 4.4 only when archiving my application (in preparation for a TestFlight deployment). I have a working shell script that runs on the target and successfully updates the info.plist file for each build. My build configuration for archiving is name 'Ad-Hoc'.
Here is the script:
if [ $CONFIGURATION == Ad-Hoc ]; then
echo "Ad-Hoc build. Bumping build#..."
plist=${PROJECT_DIR}/${INFOPLIST_FILE}
buildnum=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "${plist}")
if [[ "${buildnum}" == "" ]]; then
echo "No build number in $plist"
exit 2
fi
buildnum=$(expr $buildnum + 1)
/usr/libexec/Plistbuddy -c "Set CFBundleVersion $buildnum" "${plist}"
echo "Bumped build number to $buildnum"
else
echo $CONFIGURATION " build - Not bumping build number."
fi
This script updates the plist file appropriately and is reflected in XCode each time I archive. The problem is that the .ipa file that comes out of the archive process is still showing the previous build number. I have tried the following solutions with no success:
Clean before build
Clean build folder before build
Move Run Script phase to directly after the Target Dependencies step in Build Phases
Adding the script as a Run Script action in my scheme as a pre-action
No matter what I do, when I look at the build log, I see that the info.plist file is being processed as one of the very first steps. It is always prior to my script running and updating the build number, which is, I assume, why the build number is never current in the .ipa file.
Is there a way to force the Run Script phase to run before the info.plist file is processed?
in Xcode 4.4.1 I create new target and add to this target build phase "Run custom script", which update main target Plist. And also, you should add this target to dependencies for main target
The reason that this happens is that by the time your "Run Script" gets run, the XCode build process has already processed the project's plist file to extract the bundle version number, etc.
You can see this (probably in more detail that you want) by going to the Log Navigator in XCode (View/Navigators/Show Log Navigator), and selecting an "Archive" build.
A detailed list of build actions should appear in your main window, and one of the things near the top should be one called Process <projectname>-Info.plist. If you expand this using the icon at the right hand side, you can see the actual build command that was run.
The way that I got around this was to update both the original plist file, and also the processed one. By doing this, you get your updated build version in the current build rather than the next one.
Here's the script that I use to do this (this is Ruby, so you would need to put "/usr/bin/ruby" in the interpreter box to use this, but the concept works the same with a shell script or any other scripting language):
def incrementBundleVersion(file)
oldVersion = `/usr/libexec/Plistbuddy -c "print :CFBundleVersion" #{file}`.strip
components = oldVersion.split('.')
newBuild = components.pop.to_i + 1
version = components.push(newBuild).join('.')
print "Updating version: #{oldVersion} -> #{version} : #{file}\n"
system("/usr/libexec/PlistBuddy -c \"Set :CFBundleVersion #{version}\" #{file}")
end
incrementBundleVersion("#{ENV['PROJECT_DIR']}/#{ENV['INFOPLIST_FILE']}")
incrementBundleVersion("#{ENV['CODESIGNING_FOLDER_PATH']}/Info.plist")
Note that the processed file #{ENV['CODESIGNING_FOLDER_PATH']}/Info.plist is a binary plist file, so you won't be able to process it with simple text tools - using plistbuddy is the easiest way to handle this, and it automatically works with both text and binary plist files.
Mark (et al), I believe I've run into the same problem you are facing, and i will try to describe it in one sentence and then explain:
I think /usr/libexec/PlistBuddy, when run from inside Xcode, works on cached versions of the Info.plist data, and thus what gets finally written for execution on device or simulator is not always what you want.
I had tried writing post Copy Resource Bundle "Run Scripts" in order to change this info in a way that wouldn't cause it to change within my local git repo, only to discover that, whereas the information would work properly when the PlistBuddy commands were executed in a terminal.app window beside Xcode, if not done, the cached values would get written.
I finally resigned myself to running the version-info generation scripts prior to the Copy Bundle Resources phase and just auto-committing the changes in another Run Script, using the same tags for the git message and for the git tag that get auto-created. for the Settings.bundle/Root.plist file, rather than commit this every time, i preferred to just run a finalization script that would perform a 'git checkout -- ${PROJECT}/Resources/Settings.bundle/Root.plist' (which is where mine exists, but may not be where everyone puts their own system settings resource file).
between the checking for changes, running parts of it at install and parts of it every time, and having the finalization scripts at the end, there are 6 scripts for some targets and 7 for another …
… but the important thing to me is that it's finally properly automated … and gets around whatever PlistBuddy is doing to my plist files when processed inside of Xcode.
I do not want an Archive build to succeed unless my working directory is clean. Therefore, I want to add a "Run Script" build phase (or something similar) to my Xcode project such that:
IF I am performing an Archive build...
AND there are uncommitted changes in my source directory
THEN the build fails with an error.
I'm working with Xcode 4 and git 1.7.
What's a good, concise, reusable script that will do the job?
Here's the script I've come up with:
#!/bin/sh
if [ -z "$(git status --porcelain)" ]; then
TAG=`date +xcarchive-%Y%m%d-%H%M%S`
echo "Working directory clean, creating tag ${TAG}"
git tag -a -m "Xcode Archive created" ${TAG}
exit 0
else
echo "error: Working directory dirty, stopping build"
exit 1
fi
As a bonus, it creates a tag if the working copy is clean.
The clean/dirty check is based on this question (which I forgot I had proposed an answer for).
If you don't want to create a tag, remove the git tag line.
If you don't want to stop the build, remove the exit 1 line.
To install this in a project:
Put this in a file in your project directory (I called it ArchiveHousekeeper.sh) and make sure the executable bit is set (chmod +x)
In your Xcode Project, add a new "External Build System" target
Name: "Archive Housekeeper" (or whatever you like)
Build Tool: ./ArchiveHousekeeper.sh
On the Xcode menu, select Product -> Edit Scheme...
In the Build section, add the new target, then uncheck all the boxes except the one in the Archive column. This ensures the script will only be run on Archive. (See this question for an explanation and a nice screenshot.)
Now try to create an archive, and watch it fail because you haven't checked in these changes!
It would be nice if Xcode 4 Pre- and Post- actions could be used for this (so you don't need to create a "fake" target), but they don't seem able to affect the build, and also I have no idea in what directory they are executed, what environment variables are available, or where their output goes.
I need to run a custom build script in xcode 4. The script is added as pre-action and executed properly. My problem is, that there are no environment variables available that could help me to access my project files.
I.e. I'm interested in ${PROJECT_DIR}, ${BUILT_PRODUCTS_DIR} and ${INFOPLIST_PATH}. Unfortunately the variables are not set. The whole environment looks like that:
Apple_PubSub_Socket_Render=/tmp/launch-pc2V6P/Render
BASH=/bin/sh
BASH_ARGC=()
BASH_ARGV=()
BASH_LINENO=([0]="0")
BASH_SOURCE=([0]="/Users/melle/Projects/rc-control/RC/Scripts/preBuild.sh")
BASH_VERSINFO=([0]="3" [1]="2" [2]="48" [3]="1" [4]="release" [5]="x86_64-apple-darwin10.0")
BASH_VERSION='3.2.48(1)-release'
COMMAND_MODE=unix2003
DIRSTACK=()
DISPLAY=/tmp/launch-VH6onm/org.x:0
EUID=502
GROUPS=()
HOME=/Users/melle
HOSTNAME=zack.fritz.box
HOSTTYPE=x86_64
IFS=' '
LOGNAME=melle
MACHTYPE=x86_64-apple-darwin10.0
OPTERR=1
OPTIND=1
OSTYPE=darwin10.0
PATH=/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin
PIPESTATUS=([0]="0")
POSIXLY_CORRECT=y
PPID=43073
PS4='+ '
PWD=/private/var/folders/h2/h2tdJ2dPF943jRjJXqjNX++++TM/-Tmp-
SCHEME_ACTION_NAME='Run Script'
SHELL=/bin/bash
SHELLOPTS=braceexpand:hashall:interactive-comments:posix
SHLVL=3
SSH_AUTH_SOCK=/tmp/launch-LXX6Lp/Listeners
TERM=dumb
TMPDIR=/var/folders/h2/h2tdJ2dPF943jRjJXqjNX++++TM/-Tmp-/
UID=502
USER=melle
_=PWD
__CF_USER_TEXT_ENCODING=0x1F6:0:0
Is this a bug in xcode4 or is it me, doing it totally wrong?
My current workaround is to abuse ${BASH_SOURCE} to find the way back to my project directory...
Update: It looks like this is a bug in xcode 4.0.1. If you enter the script directly into the Xcode window, at least the variable ${WORKSPACE_PATH} is available.
I found that adding the script to the target's build phase rather than as a pre-action was a better solution in my case:
Select the Project in the project navigator.
Select your target.
Go to the Build Phases tab.
Add a new build phase (script).
Drag it above the compile sources phase.
Add whatever script you need there. You can access environment variables such as ${PROJECT_DIR}.
You can even have it output all the environment variables in the Log Navigator for you.
Additionally, the working directory for any scripts you call will be set to the project's directory automatically.
What I did:
I have a script that
Read some configuration files to generate source code snippets
Find relevant Objective-C source files and
Replace some portions of the source code with the generated code in step 1.
and a Makefile that has a special timestamp file as a make target and the configuration files as target sources:
SRC = $(shell find ../config -iname "*.txt")
STAMP = $(PROJECT_TEMP_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME).stamp
$(STAMP): $(SRC)
python inject.py
touch $(STAMP)
I added this Makefile as a "Run Script Build Phase" on top of the stack of build phases for the project target.
What happened:
The script build phase was run before compiling the source.
However, since the script modifies source code during its execution, I needed to build twice to get the most recent version of the build product. Here is what I imagine to be happening:
1st run: Xcode collects dependency information ---> no changes
1st run: Xcode runs "Run Script Build Phase" ---> source is changed behind Xcode's back
1st run: Xcode finishes build, thinking nothing needs to be updated
2nd run: Xcode collects dependency information ---> source has changed, needs rebuild!
2nd run: Xcode runs Run Script Build Phase" ---> everything is up-to-date
2nd run: Xcode proceeds to compilation
After reading Xcode documentation on Build Phases, I tried adding a source file which is known to be updated every time the script is run as the output of "Run Script Build Phases", but nothing changed. Since the number of configuration files may vary in my project, I don't want to specify every input and output file.
Question:
How do I make Xcode aware of source file changes made during "Run Script Build Phase"?
Edit:
Added that I placed the script build phase before the other build phases
Every technique mentioned so far is an overkill. Reproducing steve kim's comment for visibility:
In the build phases tab, simply drag the "Run Script" step to a higher location (e.g. before "Compile Sources").
Tested on Xcode 6
This solution is probably outdated. See the higher voted answer instead; I no longer actively use Xcode and am not qualified to vet a solution.
Use "External Target":
Select "Project" > "New Target..." from the menu
Select "Mac OS X" > "Other" > "External Target" and add it to your project
Open its settings and fill in your script setup
Open the "General" tab of the main target's settings and add the new target as it's direct dependency
Now the new "External Target" runs before the main target even starts gathering dependency information, so that any changes made during the script execution should be included in the build.
There is another, slightly simpler option that doesn't require a separate target, but it's only viable if your script tends to modify the same source files every time.
First, here's a brief explanation for anyone who's confused about why Xcode sometimes requires you to build twice (or do a clean build) to see certain changes reflected in your target app. Xcode compiles a source file if the object file it produces is missing, or if the object file's last-modified date is earlier than the source file's last-modified date was at the beginning of the first build phase. If your project runs a script that modifies a source file in a pre-compilation build phase, Xcode won't notice that the source file's last-modified date has changed, so it won't bother to recompile it. It's only when you build the project a second time that Xcode will notice the date change and recompile the file.
Here's a simple solution if your script happens to modify the same source files every time. Just add a Run Script build phase at the end of your build process like this:
touch Classes/FirstModifiedFile.m Classes/SecondModifiedFile.m
exit $?
Running touch on these source files at the end of your build process guarantees that they will always have a later last-modified date than their object files, so Xcode will recompile them every time.
As of Xcode 4, it looks like if you add the generated files to the output section of the build phase, it will respect that setting, and not generate the ... has been modified since the precompiled header was built error messages.
This is a good option if your script is only generating a handful of files each time.
I as well struggled with this for a long time. The answer is to use ento's "External Target" solution. He is WHY this problem occurs and how we use it in practice...
Xcode 4 build steps do not execute until AFTER the plist has been compiled. This is silly, of course, because it means that any pre-build steps that modify the plist won't take effect. But if you think about it, they actually DO take effect...on the NEXT build. That's why some people have talked about "caching" of plist values or "I have to do 2 builds to make it work." What happens is the plist is built, then your script runs. Next time you build, the plist builds using your modified files, hence the second build.
ento's solution is the one way I've found to actually do a true pre-build step. Unfortunately I also found that it does not cause the plist to update without a clean build and I fixed that. Here is how we have data-driven user values in the plist:
Add an External Build System project that points to a python script and passes some arguments
Add user-defined build settings to the build. These are the arguments that you pass to python (more on why we do this later)
The python script reads some input JSON files and builds a plist preprocessor header file AND touches the main app plist
The main project has "preprocess plist files" turned on and points to this preprocessor file
Using touch on the main app plist file causes the main target to generate the plist every time. The reason we pass in build settings as parameters is so our command-line build can override settings:
Add a user-defined variable "foo" to the prebuild project.
In your prebuild you can use $(foo) to pass the value into the python script.
On the command-line you can add foo=test to pass in a new value.
The python script uses base settings files and allows for user-defined settings files to override the defaults. You make a change and immediately it ends up in the plist. We only use this for settings that MUST be in the plist. For anything else it's a waste of effort....generate a json file or something similar instead and load it at run-time :)
I hope this helps...it's been a couple rough days figuring this out.
The External Target solution from #ento no longer works as of Xcode 11.5. The solution is to add all files that will be changed under Output Files in the Run Script.
Another option is to create a subproject framework with your scripts and just add it as a dependency to all targets. The phase scripts of this subproject should now be executed before all targets.