I have a project which builds two targets, the main app and a tool.
How can I correctly include the tool in the app bundle? I have already navigated to target dependencies and added the tool; however when adding the built executable to the "Copy Bundle Resources" phase, I get a path to the builded product like:
.../.../awieuhfaowasldijfsalkdj/Build/Debug/tool
Is there any way to add the tool to the bundle dynamically, I mean without hardcoding such path? Ideally, I'd like to add the tool in a special folder (say "Tools") inside the "Resources" bundle folder, but I don't even know if that's possible.
Apart from this, is there something else I need to do in order to complete the process of adding it as a resource?
One simple way to avoid the weird path is to specify that the build location should be the one specified by the targets (by default build/Debug or build/Release under the project folder):
Open the Xcode preferences
Click on the Locations tab
Under Build Location, select Place build products in locations specified by targets
Related
I want to attach some file as option in TeamCity 8.1 Build Run dialog form.
Before start build this file must be copied into defined place on the Agent side.
Who knows, is it possible? I can't find any plugins for it.
Tnx.
Where does this file normally reside? ie: where would TeamCity get it from?
Where should this file be copied to on the build agent? Can it be placed in the sandbox (work folder) for a given project?
If the file is stored in source control, you can specify a VCS root to get it copied over to the sandbox the same way you specify a VCS root to get the source code you wish to build copied to the sandbox.
For our projects, we regularly specify two VCS roots for a single project: one to copy some scripts and utilities our build requires and one to copy the actual source code that needs to be built.
Hope that helps!
The tile basically says it all.
I'm developing a mac app which has the normal app target, but also has two more command-line tool targets whose products are copied to the app when building. I remember seeing somewhere that the "Skip install" was important in these cases, but I remember nothing of what I read, so this might be incorrect.
Anyway, I just wanted to know what this option affects.
I believe this only matters when you're developing for the App Store. If you archive your app target and this includes building other targets (command line tools, static libraries, ...), all the targets' products are copied into the archive, unless SKIP_INSTALL is set to YES.
You can verify this: Archive your application, find the archive in the Organizer, Option-Click --> "Show in Finder", go into the archive (Option-Click --> "Show Package Contents"), and in /Products you will find multiple files/folders. However, App Store builds only allow one product within the Products directory. Xcode warns you about this if you "Validate" your archived app in the Organizer:
When you set SKIP_INSTALL=NO (which is the default), the build target will be installed to $(DSTROOT)$(INSTALL_PATH) during the build phase. Setting SKIP_INSTALL=YES causes the target to be built but not installed.
Setting SKIP_INSTALL=YES can be useful for static archives (libsomething.a) that will be later linked into other targets or bundles that will be installed by another target's copy-files build phase.
Skip Install (SKIP_INSTALL)
In case with archive
xcodebuild archive SKIP_INSTALL=NO
NO - allows to put data into <some_path>/<some_name>.xcarchive/Products or install a framework in archive
Overview
I'm using static libraries and Xcode 4 workspaces to effect modularity in iOS development, an increasingly common technique. For example, I might have a workspace which contains an App project, and a Library project, like so1:
You would then have a scheme to build these that looked something like this:
What I would like to do is have the "App build" control the "Library build" it initiates, in at least a couple of ways:
Map App configurations (e.g. Debug, AdHoc) to arbitrary Library configurations
Passing through some subset of -D defines, and/or specifying these for the library build.
I'll deal with each of these in their own section, but it's worth making a few clarifications.
Clarifications
I'm using App/Library here as an easy proxy for any Superproject/Subproject relationship you may have.
From what I've seen, Xcode 3 style embedded subprojects don't seem to work any differently in Xcode 4 than workspace "peers". I'd love to be wrong about this.
I know I could do almost anything with a "Run Build Script" build phase, and xcodebuild. But I'm trying to work within the system here, where the dependencies are specified in the scheme, and otherwise somewhat loosely coupled.
The Library exists to be used in more than just this project, and so you cannot arbitrarily load it up with junk specific to this App's build, or reference anything particular to the App or Workspace. For the general case, this rules out including static .xcconfig from the App project as a way to convey build information from the App to the Library.
Building the Library outside the workspace sacrifices too much, not an option.
Configuration Mapping
As I understand it, building a particular App configuration will:
If a configuration exists in the Library of the same name, it will build the Library using that.
Otherwise, it will build the active configuration of the Library, as specified in the Library's project file.
To my knowledge, without resorting to the aforementioned run-build-script hack, that is the extent of the control one has over subproject build configurations. Please tell me different.
Ideally, I would be able to specify (in the scheme, presumably):
AppConfigA -> LibConfig1
AppConfigB -> LibConfig2
While Debug, AdHoc, & Release may be the only configurations some ever use, complex projects often outgrow that.
Defines
I've not yet found way to pass -D defines from the App build to the Library, without resorting to xcodebuild, which can take, e.g., an .xcconfig file.
The App's build settings can be accessed in Library build run-build-script phase. However, doing that introduces a dependency in the Library on the App project, which for good reason is verboten (cf. Clarifications). But even then, I haven't found a way to use those settings to directly control the Library's build (much2).
So crazy it just might...
One scheme I came up with while writing this would be:
The Library bases it's build configurations on an empty (dummy) LibraryExternals.xcconfig file within it's own project.
A clean of Library deletes that file. A standalone build of the Library will create an empty one if it does not already exist.
That file is overwritten by an App Build run-build-script phase, and contains anything the app wants to communicate to the Library build.
Seems kind of complicated, but I'm looking for anything right now. I'll push this to an answer if nothing better comes along.
1 Apps shown are Max OS X. I find command line apps make for simpler tests. Same applies.
2 Cf. Info.plist preprocessing, which I learned about during this investigation.
If you modify your project structure to use a single project with multiple targets then each target's build settings will automatically inherit from the project. From there, you can modify ones that you want to be different, or select an individual setting and press the delete key to set it to the default specified by the project.
I need to assemble resources for an application depeding on XCode build settings. The easiest way to achieve this, is through a build script phase. Although this works, this somehow always builds my target with resources one version lagging (a second build is needed to get things really up-to-date).
The Resources folder is a reference to a folder in which my script (or rather, custom built command line tool called from script) copies the appropriate resources. The run script build phase is the first (topmost) phase in my target.
A solution I've found on the web somewhere, is to create an "External Target" and add that to the original target's build phases (by dragging the External target onto the original target). This does indeed seem to fix the "one version behind" issue, but I cannot seem to get the current target's environment variables to be passed to this "External target".
Why is XCode not including the just updated resources? What other alternatives are there?
You could try to define an internal target (say, "ResourceTarget") and make the main target dependent on ResourceTarget. Then let your script run in the script build phase of ResourceTarget, so the resources are all updated when the second target is build.
That way, environment variables should be the same.
I'm working on an iOS app project, and add the json-framework project to the workspace. The project navigator on the left shows both projects, and the build scheme selector shows the schemes from both projects too. Now I want to add the libjson.a target from the json-framework project as a dependency on the iOS app target in the other project. The expected result is that whenever the app target is built, it builds (if necessary) the library target and links the app target against it. Here are the ways I've tried to do this:
Build both as part of the same scheme. The way I try this is to edit the scheme for my app, adding 'libjson.a' to the 'Build' portion of the scheme, and by the way "Find Implicit Dependencies" is checked. Then I go to the target editor for my app target, and in "Build Phases"->"Link Binary With Libraries", I choose 'libjson.a' from the list of workspace libraries.
When I subsequently try to build the scheme, I see it build the library target, but building the app target fails with linker error "Library not found for -ljson" - suggesting that it hasn't actually discovered that the library has been built. Indeed in the project navigator, the entry under the app project for the library is still red indicating that the file doesn't exist.
Add the json target as an explicit dependency. To try this, I don't modify the build scheme, but go to the target editor for my app target and click the add button under 'Target Dependencies'. No targets from other projects in the workspace show up, so this is a non-starter.
Drag the JSON project into the other project, then add the target as a dependency. This is what I would have done in Xcode 3. In the project navigator, I grab the library project and drag it over the app project. This brings up the usual 'add files' pane, which I just dismiss by clicking 'Finish'.
There are now two entries for the library project in the project navigator: one at the top level, and one under the app project. I can now add the library target as a dependency of the app target using the target editor, and can link against it without error in the link libraries phase. But it looks broken: there are multiple entries for the same project in the navigator. Is there a different way to do this?
What should be considered the "Xcode 4-ish" way of connecting these targets in different projects in the same workspace? It would seem lacking if multiple projects in the same workspace can't actually interact with each other.
Thanks,
Graham.
I’ve just set a test project up, pretty much as you describe in version 3, by creating a new workspace and dragging the two Xcode project into it, nested as shown.
You can delete the sibling project if you have it already.
Hitting build on this and it just works, as far as I can see.
I imagine there is internal path-confusion if you have two projects, and I’d be inclined to fiddle with location settings in "View"->"Utilities"->"File Inspector" and see what effect that has.
Another thing to try is to set your paths up in Xcode "Preferences…"->"Source Trees" and refer to them that way, as described here: Easy, Modular Code Sharing Across iPhone Apps: Static Libraries and Cross-Project References
HTH. Andy W.
I managed to get dependencies between projects in a workspace to work as I described here: http://blog.carbonfive.com/2011/04/04/using-open-source-static-libraries-in-xcode-4/.
Unfortunately I can't find a way to get Xcode to discover implicit dependencies or index everything in the build as advertised. I found workaround to both but I'm hoping that less manual configuration will be needed as Xcode 4 matures.
I was going to ask the same question, thinking that my own solution couldn't be right. But I don't see it mentioned here, and it does seem to work. Clearly XCode 4 is a work in progress. :)
I have a workspace with two projects: a static library and an app which uses the library. The projects are siblings. Each project has its own scheme, and each scheme is set to only build one target. In other words, I added two projects to the workspace and that's it.
To add the static library as a dependency of the app, I just drag the libsomething.a product from the library project (Project Navigator) into the "Link Binary with Libraries" list for the app target. That's it. Now when I build the app the library project is built first and then linked. Interestingly, when I modify the app's scheme to use a different configuration (eg, Release instead of Debug), the library is built using the same configuration.
So it works, and there is clearly some automatic dependency checking going on here. But it feels wrong. Then again, so does the modal scheme editor/manager and lack of a workspace object in the project navigator... I never thought I'd say it, but the Visual Studio UI (bleh) is a lot clearer.
My bullet-proof solution to do this :
Create "Per Debug-Release / Per Architecture" settings in Build Settings in the Main project (not the lib), to include either
../MyLibProject/build/Debug-iphoneos
or
../MyLibProject/build/Release-iphonesimulator
or
etc..
depending on the configuration (you can create those kind of configuration by clicking on the + next to Debug or Release and choose either "Any iOS Simulator SDK" or "any iOS SDK".
You need to do that for both "Header Search Path" (in case your library copy some headers files, which is more than likely) AND for "Library Search Paths". Which means that for each setting, you'll probably end-up with 4 different paths (debug sim , debug ios, release sim, release ios).
That would make sure the configuration of both projects match.
Now, to auto-compile the lib, that is to create the dependency, you can use the "Build Phase -> Link to Binary With Libraries -> + -> select the .a file" advice given above.
That's the only way I managed to have something that builds and link correctly for every environment on xcode 4.5
Note : I even added the -lmyLib flag in "other linker flags", but i'm not sure that's really necessary
I've had some success with creating framework-like static libraries, though it's not a perfect solution.
I see the next variants:
Explicit dependency in a project[About]
Implicit dependency in a workspace[About]
See the Xcode user guide: Xcode Concepts -> Xcode workspace under 'Projects in a Workspace Share a Build Directory'.
All projects in a single workspace share a build directory. Dependencies are discovered automatically and build if needed:
"Xcode examines the files in the build directory to discover implicit dependencies. For example, if one project included in a workspace builds a library that is linked against by another project in the same workspace, Xcode automatically builds the library before building the other project, even if the build configuration does not make this dependency explicit. You can override such implicit dependencies with explicit build settings if necessary. For explicit dependencies, you must create project references."