2013-10-01 3 views
5

Документация XCode по понятиям Targets и Projects полезны, но все же я не уверен в лучших практиках, которые могут быть использованы в моей ситуации.Проекты Vs Цели для кодовой базы в рабочей области XCode

У меня есть существующая кодовая база (используемая как для Windows, так и для iOS) в одном репозитории SVN, который только что был реорганизован из одного тестового приложения в центральную библиотеку и приложение. Идея больше приложений будет использовать эту центральную библиотеку с течением времени.

Проект XCode отображает один набор исходных файлов на одну или несколько целей, поэтому у меня может быть один проект для всей моей кодовой базы и одна цель для библиотеки и по одному для каждого приложения. Однако у каждого приложения, очевидно, будет свой собственный код, поэтому кажется немного неуклюжим бросить весь источник в один проект таким образом.

В качестве альтернативы я мог бы иметь рабочее пространство с несколькими проектами, каждый из которых имеет одну цель. Это гораздо больше, так как я создал вещи для сборки Windows, где решение Visual Studio соответствует рабочему пространству Xcode, а проект VC++ будет аккуратно сопоставлять с тем, как организованы проекты XCode.

Но есть ли «нормальные»/ожидаемые способы сделать что-то в этой ситуации, некоторые неофициальные стандарты, которые я должен попробовать, чтобы другие разработчики не путались?

+0

попытайтесь создать проект библиотеки из библиотеки :) Он будет создавать статическую или динамическую библиотеку в качестве цели.Затем другие проекты могут связывать его с целями, ссылаясь на проект lib – tuxSlayer

ответ

4

В настоящее время целевые назначения используются для создания зависимостей и отдельных сборок внутри проекта. Вы увидите, что он используется в основном для модульного тестирования. Иногда у вас могут быть разные исполняемые файлы для разных процессоров или операционных систем, но это редкость в сегодняшнем мире приложений.

Как правило, у вас будет один проект для каждого исполняемого файла. Это позволяет обрабатывать самостоятельно и составлять отдельно, не мешая друг другу.

Вы можете включать проекты в проекты, которые позволяют вам работать над ними независимо и устанавливать для них зависимости. Вы можете настроить проект для создания подпроекта и внести его в исполняемый файл в месте, к которому будет привязан ваш проект.

Я бы сказал, что для вашей ситуации создайте проект библиотеки с исполняемыми и тестовыми целями. Затем включите этот проект в другие проекты, и вы можете связать или переместить файлы в другое место вашего проекта. Here's the gist of how to do it.

Я знаю, что вы не упоминаете их, но рабочие области были в основном добавлены, чтобы позволить вам открывать несколько проектов в одном окне. Вы можете использовать все ваши тестовые приложения и ссылочный код без их компиляции в фоновом режиме. Я считаю, что это очень удобно.

0

Когда я делю код между одним или несколькими проектами (будь то Xcode или другая IDE), я обычно компилирую общие части в двоичные файлы, а затем связываю их с конкретными проектами кода.

В вашей настройке что-то вроде проекта Xcode просто для компиляции dylib из общих файлов C++, а затем основного проекта Xcode, который связан с этим dylib.

1

Главное отличие состоит в том, что каждая цель находится в одном проекте, но один проект может быть частью многих рабочих областей. Это позволяет вам создавать проекты Lib, AppA и AppB, а затем WorkspaceA = [AppA, Lib] и WorkspaceB = [AppB, Lib], чтобы разработчикам, работающим над AppA, не приходилось загружать файлы, связанные с AppB. В качестве общей рекомендации рекомендуется создавать проекты для вещей, которые вы, возможно, захотите разделить самостоятельно.