Подтвердить что ты не робот

Xcode Workspace vs Nested Projects

Я не понимаю использование рабочего пространства Xcode для организации проектов с зависимостями друг от друга. Например, я вижу, что многие разработчики создают структуры рабочего пространства, которые выглядят следующим образом:

Workspace
|-- App
|-- A Common Library
|-- Another Common Library

Какая польза от этого? Если кто-либо откроет проект "App" напрямую, не сможет ли он фактически создать приложение? Им нужно было бы понять, что существует рабочая область с необходимыми зависимостями.

Мне кажется, что лучше использовать такие вложенные проекты, как это:

App
|-- Libraries
|   |-- A Common Library
|   |-- Another Common Library

Тогда не существует никакого проекта, который не может быть построен. Это также похоже на идею Git идеи подмодулей.

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

4b9b3361

Ответ 1

Я использую рабочие области, когда хочу объединить проекты, а также поддерживать независимость проекта.

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

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

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

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

Иногда я даже совмещаю рабочие пространства с проектами, содержащими встроенные проекты.

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

Ответ 2

Мы добавили вложенные проекты в основные рамки проекта, чтобы мы могли "включить" их в продукт .framework.

Main
|-- Main
|-- MainTests
|-- Frameworks
|   |-- CommonLibrary.xcodeproj
|   |-- AnotherCommonLibrary.xcodeproj
|   |-- UIKit.framework
|   |-- Foundation.framework
|   |-- CoreFoundation.framework
|-- Products

См. это отличное учебное пособие Джеффом Веркойеном для добавления Universal Frameworks в проект. Сначала это нелегко, но продолжайте работать над этим, и вы получите его.