(Also posted to the Apple dev forums, to the sound of crickets. Sorry for the duplicate post of you frequent both locations...)
Our company has quite a few apps for Mac and iOS that have a number of build schemes. Some of our projects include command-line tools to build components that go into the project.
We often have 4 or 5 different build schemes for a project (debug, ad hoc, app store, invoking command line tools with different launch parameters, etc.)
We use git with repositories hosted on xp-dev to manage our source repositories.
Build schemes do not get included in the repository. Each person who checks out a project has to manually create all the schemes. This is especially problematic for projects that we're doing for clients. After they check out a project on a new machine, we have to screen-share with them and set up the schemes for them, which is tedious and error-prone.
I check the "share" button in the scheme editor, but it doesn't change anything.
We do use a .gitignore file to keep user-level files out of the repository, but I don't think that is the problem. After checking share in the Manage Schemes sheet, I can see the schemes in the xcshareddata>xcschemes folder, but those files are not added to the repository.
What is the secret to getting Xcode build schemes checked into a remote git repository?
On a related subject, is it possible to specify launch arguments to an app that are based on environment variables? A project we're building for a client includes a command-line tool that we want to be able to run from Xcode. I'd like to be able to pass it the names of a couple of folders inside the project, using the project folder name as the root of the path. Can you do that? If so, how?
Thanks in advance for any help with this.
EDIT: I just answered the second part of this question myself. It seems that the "Arguments Passed On Launch" items support environment variables like the rest of the build process. I added a parameter
As an argument to my image tiling command line utility. That causes it to expand "${PROJECT_DIR}" to the current project dircetory, which is exactly what I need.
Our company has quite a few apps for Mac and iOS that have a number of build schemes. Some of our projects include command-line tools to build components that go into the project.
We often have 4 or 5 different build schemes for a project (debug, ad hoc, app store, invoking command line tools with different launch parameters, etc.)
We use git with repositories hosted on xp-dev to manage our source repositories.
Build schemes do not get included in the repository. Each person who checks out a project has to manually create all the schemes. This is especially problematic for projects that we're doing for clients. After they check out a project on a new machine, we have to screen-share with them and set up the schemes for them, which is tedious and error-prone.
I check the "share" button in the scheme editor, but it doesn't change anything.
We do use a .gitignore file to keep user-level files out of the repository, but I don't think that is the problem. After checking share in the Manage Schemes sheet, I can see the schemes in the xcshareddata>xcschemes folder, but those files are not added to the repository.
What is the secret to getting Xcode build schemes checked into a remote git repository?
On a related subject, is it possible to specify launch arguments to an app that are based on environment variables? A project we're building for a client includes a command-line tool that we want to be able to run from Xcode. I'd like to be able to pass it the names of a couple of folders inside the project, using the project folder name as the root of the path. Can you do that? If so, how?
Thanks in advance for any help with this.
EDIT: I just answered the second part of this question myself. It seems that the "Arguments Passed On Launch" items support environment variables like the rest of the build process. I added a parameter
Code:
"${PROJECT_DIR}"/iCaverns_new/Images/Images\ for\ tiling
As an argument to my image tiling command line utility. That causes it to expand "${PROJECT_DIR}" to the current project dircetory, which is exactly what I need.
Last edited: