re: Project dependencies
re: Project dependencies
- Subject: re: Project dependencies
- From: "j.carlson" <email@hidden>
- Date: Wed, 28 Aug 2013 14:15:53 -0400
> Date: Tue, 27 Aug 2013 22:38:58 -0700
> From: Jim Geist <email@hidden>
> Subject: Project dependencies
>
> I have a system that has several targets and some shared code. It is organized as a main application which was created with the initial workspace, several projects of static libraries which contain shared code between the main app and a utility app, and a project for the utility app. (There will eventually be more tool projects sharing the same libraries.)
>
> For the main application, I was able to add the static library projects as target dependencies. However, when I click to add target dependencies to the utility app, none of the other projects or targets show up as addable.
>
> I have a theory that this might be because the utility app is a child of the workspace/main app, and is therefore a sibling of the static libraries.
Right. Utility's project does not have a (direct) reference to the projects which own the dependent targets. Therefore, they are inaccessible to Utility.
> Does anyone have a suggestion as to how to structure the workspace so that this will work?
1. You can add the projects to Utility.xcodeproj, then they will of course appear.
2. You can create a new project which provides an intermediate (proxy) static library target (you'll need one object plus the referenced library). Then you can add all the wrappers you need into one project.
3. Perhaps better in this scenario: You have a collection of libraries which are used by both. Create a new static library target which serves to glue all dependent shared static libraries together (linking one trivial object + all dependent libs). This also can be useful if there is not a 1:1 mapping of products, but you have abstract/evolving collections of smaller libraries composing a more general set of dependencies.
So you can choose based on how many tools/targets you will create, and which structure makes the most sense in that context. If you are going to have a lot of tools, I would use nr.2 or 3 because you can update all from one point (i.e. can save you from multiplied work in the future).
Personally, I have not found Xcode's implicit dependency feature usable. Maybe it is presently, but it has failed several times in the past so I just continue to disable it by default. Yes, it is pretty reliable with small projects, but fails in larger projects -- which may contain dozens of dependencies or sub-dependencies. So my build approach hardly changed when workspaces and schemes were introduced with Xc4; it's still largely structured like Xc3's (i.e. projects, targets, and explicit dependencies).
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden