Xcode Build Phase Input Folder

This is the answer from a developer who can afford going beyond the Xcode's IDE capabilities.

As far as I got your question you have some IN stuff which you want to do some processing on it so that that processing results in some OUT stuff. Let's call this Subproject: something that contains IN, OUT and processing: IN -> OUT. And you want this processing to be incremental: do not repeat the same work if it is already done i.e. if OUT is there and IN was not modified do not perform processing IN -> OUT because result already exists.

For this kind of task I use Make (any other build system is fine, e.g. Ninja) which is exactly the tool which does this job: you describe what you need, describe what you have and the process of transformation, and it works and gives you incremental processing.

Instead of tinkering at Xcode's build phases in your Run Script phase you can just put cd Subproject; make and delegate everything related to your IN -> OUT processing to Make by writing proper Makefile. The only thing that will remain in Xcode is Run Script phase which performs this delegation of your build rules to Make.

I have created example that addresses your question and demonstrates the integration of Make-based subproject into Xcode project: Xcode and Make.

├── README.md
├── Subproject
│   ├── Generated-Code
│   │   ├── file1.out
│   │   ├── file2.out
│   │   └── file3.out
│   ├── Makefile
│   └── Source
│       ├── file1.in
│       ├── file2.in
│       └── file3.in
└── Xcode-and-Make
    ├── Xcode-and-Make
    │   └── main.m
    └── Xcode-and-Make.xcodeproj
        └── project.pbxproj

The custom stuff is isolated in Subproject folder. This folder is included to Xcode project: Generated-Code .out files are included to the project's main target, *.in files are not included, Makefile is also not included.

In project's Run Script phase there is only call to Make:

cd ../Subproject
make

All the Source/*.in -> Generated-Code/*.out processing is done in Makefile which is written like:

IN_PATH=./Source
IN_FILES=$(wildcard $(IN_PATH)/*.in)

OUT_PATH=./Generated-Code

OUT_FILES := $(patsubst %, $(OUT_PATH)/%, $(notdir $(IN_FILES)))
OUT_FILES := $(patsubst %.in, %.out, $(OUT_FILES))

default: generate

generate: $(OUT_FILES)

clean:
    rm -rf $(OUT_PATH)

$(OUT_PATH)/%.out: $(OUT_PATH) $(IN_PATH)/%.in
    cp -v $(IN_PATH)/$*.in $(OUT_PATH)/$*.out

$(OUT_PATH):
    mkdir -p $(OUT_PATH)
    

If you are new to Make all this notation can be confusing at first but after one day of reading tutorials about Make you'll have basic understanding of how Make works.

This Makefile is written to give you incremental processing: cp is just trivial demo operation which copies *.in to *.out - in real application it can be a compiler or some other tool.

When inside Subproject folder you write make for the first time you see:

Subproject$ make
mkdir -p ./Generated-Code
cp -v ./Source/file1.in ./Generated-Code/file1.out
./Source/file1.in -> ./Generated-Code/file1.out
cp -v ./Source/file2.in ./Generated-Code/file2.out
./Source/file2.in -> ./Generated-Code/file2.out
cp -v ./Source/file3.in ./Generated-Code/file3.out
./Source/file3.in -> ./Generated-Code/file3.out

But on the second run you get:

Subproject$ make
make: Nothing to be done for `default'.

that's because Make is smart to understand that you didn't perform any modifications of any of *.in files so to make Make perform its processing again you need to actually perform some change in *.in files and this is exactly what you original question is about.

I think the example project is the best showcase so feel free to decide if this drift away from Xcode's defaults makes you feel comfortable about it and feel free to ask if you have any further questions.

Disclaimer: I have been using Make for 2 years for (almost) everything that involves building something that Xcode cannot handle so I strongly recommend you to learn basics of Make: it can be very powerful tool for build scripts in which incremental processing is nice to have.

Xcode requires the input files to be within $SRCROOT directory, and the output files to be within $DERIVED_FILE_DIR directory, or else it will run the script on every build.

Sadly, you can't use a recursive path for the input files. (Please submit a FeedbackAssistant ticket to Apple to request this.)

You have to use an .xcfilelist, and keep it updated. In order not to have to update it manually, you would need some other script that runs during a pre-build scheme script, which checks whether each target's current .xcfilelist accurately reflects all the files you want the script to target. Obviously, this is a pretty annoying kind of solution if you have lots of schemes.

So I went with a workaround, namely:

• specify $(SRCROOT)/$(INFOPLIST_FILE) as the sole input file
• specify $(DERIVED_FILE_DIR)/X.plist as the sole output file
• at the beginning of the script copy the input file to the output file
• then perform the main work of the script

E.g.:

set -ex

if [ -f "$SCRIPT_OUTPUT_FILE_0" ]; then
    echo "$SCRIPT_OUTPUT_FILE_0 exists. This script should not even be running"
    exit 0
else
    cp -a $SCRIPT_INPUT_FILE_0 $SCRIPT_OUTPUT_FILE_0
fi

This ensures the script only runs on clean builds (i.e., the first build after you clean your build folder or erase DerivedData/YourWorkspace/Build).

Unfortunately this means the script will never run on incremental builds, even if you change some of the files it uses as input. However this was the best compromise I could find (so far). It seems much better than resorting to MAKEFILEs etc.

A better option might be to use a Build Rule.