On Nov 15, 2005, at 7:57 AM, Shawn Erickson wrote: You may want to try a solution that involves a Run Script build phase that writes an .xcconfig file with the CURRENT_PROJECT_VERSION = xx key/value pair, then #include that fine from an .xcconfig file in your target.
Note sure I follow the above. How do you get an external file to affect target settings?
It turned out to be tougher than I expected. Due to caching of file data and dependencies, though, you can't just dynamically change the contents of a target's .xcconfig file in the middle of that target's build. So you need to factor the version bump into a separate target. Here's the gist:
- Add an Xcode Build Configuration File to the target called currentversion.xcconfig. Set its contents to
CURRENT_PROJECT_VERSION = 1
- Add an Xcode Build Configuration File to the target called config.xcconfig. Set its contents to
#include "currentversion.xcconfig"
- Add a new Run Script target to the project, called Increment Version. Set its script to
/usr/bin/perl -pe 's/(CURRENT_PROJECT_VERSION = )(\d+)/$1.($2+1)/eg' -i ${SRCROOT}/currentversion.xcconfig
and set its Output Files to
$(SRCROOT)/currentversion.xcconfig
- In your target, set the Based On: popup to "config.xcconfig"
- Add a new Aggregate Target called Release and set its Target Dependencies to Increment Version and your main target.
Now when you build the Release target it will build the Increment Version target, which bumps the version number in the currentversion.xcconfig file, then build the main target, which is based on a config file that pulls in the sub-config file that just defines the version.
This can certainly be optimized: you might be able to combine the Aggregate and Run Script targets into one, and also use one config file instead of two. But for larger projects you will probably need the modularity, as you may have other configuration settings and other targets. You could also create the currentversion file dynamically, and perhaps in the ${DERIVED_FILES_DIR} instead of ${SRCROOT}, so that you don't have to commit it to your repository and deal with checkin conflicts with other project users
Note also that having a specific target to bump the version is preferable to making it happen with the Release configuration, so you can try Release builds without committing to a version bump.
Chris |