5

The XCode documentation on the concepts of Targets and Projects are helpful, but still I am not certain on the best practices to use in my situation.

I have an existing codebase (used for Windows as well as iOS) in a single SVN repository, which has just been refactored from one single test application into a central library and an application. The idea is more applications will use this central library over time.

An XCode project maps one set of source files to one or more targets, so I could have a single project for my whole codebase and one target for the library and one for each app. However each app will obviously have its own code, so it seems a bit clunky to throw all the source into a single project this way.

Alternatively I could have a workspace with multiple projects, each having a single target. This is much more how I have things set up for the Windows build, where a Visual Studio solution corresponds to the Xcode workspace, and a VC++ project would map neatly against how XCode projects are organised.

But are there 'normal' / expected ways to do things in this kind of situation, some unofficial standards I should try to follow so other developers don't get confused?

Mr. Boy
  • 60,845
  • 93
  • 320
  • 589
  • try to make a "library" project from the library :) It will produce static or dynamic lib, as a Target. Then other projects can link it into their targets by referring to the lib project – tuxSlayer Oct 11 '13 at 09:46

3 Answers3

4

Targets nowadays are used to build dependencies and separate builds within a project. You'll see it being used mainly for unit testing. Occasionally, you might have different binaries available to different processors or operating systems, but this is a rarity in today's app store world.

Generally, you'd have one project for each executable. This allows it to be worked on independently and compiled separately without interfering with each other.

You can include projects within projects, which allows you to work on them independently and set up dependencies for them. You can set up a project to build a sub-project and deposit it's executable in a location for your project to link to.

I would say for your situation, make a library project with executable and testing targets. Then include that project in other projects and you can link to or move the files to your other project's location. Here's the gist of how to do it.

I know you don't mention them, but workspaces were basically added to allow you to have multiple projects open in a single window. You can have all your test applications and reference code available without them compiling in the background as well. I find it super handy.

Derek
  • 1,170
  • 12
  • 16
1

The key difference is that each target is in exactly one project, but one project can be a part of many workspaces. This lets you have projects Lib, AppA, and AppB, and then WorkspaceA = [AppA, Lib] and WorkspaceB = [AppB, Lib], so that developers working on AppA don't have to load stuff related to AppB. As a general recommendation it's a good idea to create projects for things that you might want to share independently.

Ben Darnell
  • 21,844
  • 3
  • 29
  • 50
0

When I share code between one or more projects (be it Xcode or another IDE), I typically compile the shared parts into a binary and then link it to the code specific projects.

In your setup, something like an Xcode project just to compile a dylib from shared C++ files, and then a main Xcode project that links with this dylib.

SomeGuy
  • 9,670
  • 3
  • 32
  • 35