When running scripts in the Scheme's build pre/post actions, I have been struggling to determine the difference between when the action has been run through a Build, Clean or Archive. The motivation in this case is that I have a Build Post-action that increments build numbers after building^[1].
So far the best solution I have come up with is to select the "Provide build settings from" and then specify my target. This way I can detemine some things from the environment variables in the script, for example:
Does anyone know of a way to do this?
Alternatively, does anyone know if it is possible to specify Xcode configuration variables that are only set for clean vs build, much like you can restrict variables to Debug/Release or certain architectures?
[1] The reason for this being a post action is my current solution in place is to leave a market file in /tmp/ in a build-phase run script, and then when the Build Post-action runs I can detect for the presence of that file to know that this was a build. This however does not solve the issue for pre-action scripts which would (in my opinion) be a more ideal place to increment the build number.
So far the best solution I have come up with is to select the "Provide build settings from" and then specify my target. This way I can detemine some things from the environment variables in the script, for example:
ACTION is empty when building/cleaning both Debug and Release builds, but set to "install" when archiving.
CONFIGURATION is set to Debug/Release when building/cleaning Debug/Release builds respectively.
Does anyone know of a way to do this?
Alternatively, does anyone know if it is possible to specify Xcode configuration variables that are only set for clean vs build, much like you can restrict variables to Debug/Release or certain architectures?
[1] The reason for this being a post action is my current solution in place is to leave a market file in /tmp/ in a build-phase run script, and then when the Build Post-action runs I can detect for the presence of that file to know that this was a build. This however does not solve the issue for pre-action scripts which would (in my opinion) be a more ideal place to increment the build number.