Я пытаюсь понять, как работает вся экосистема iOS.
До сих пор я мог найти ответ для большей части моего вопроса (и, поверьте, их было много), но для этого, похоже, пока нет четкого ответа.
В чем разница между файлами XcodeProject и XcodeWorkspace?
Я думаю, что есть три ключевых элемента, которые вам нужно понять относительно структуры проекта: Цели, проекты и рабочие пространства. Цели подробно определяют, как создается продукт/двоичный файл (т.е. приложение или библиотека). Они включают в себя настройки сборки, такие как флаги компилятора и компоновщика, и определяют, какие файлы (исходный код и ресурсы) действительно принадлежат продукту. Когда вы создаете/выполняете, вы всегда выбираете одну конкретную цель.
Вероятно, у вас есть несколько целей, которые разделяют код и ресурсы. Этими целями могут быть несколько разные версии приложения (iPad/iPhone, разные брендинги,...) или тестовые примеры, которые, естественно, должны иметь доступ к тем же исходным файлам, что и приложение. Все эти связанные задачи можно сгруппировать в проект. Хотя проект содержит файлы со всех своих целей, каждая цель выбирает свой собственный подмножество соответствующих файлов. То же самое можно сказать и о настройках сборки. Вы можете определить параметры проекта по умолчанию в проекте, но если одна из ваших целей нуждается в разных настройках, вы всегда можете их переопределить:
Общие параметры проекта, которые наследуют все целевые объекты, если они не переопределяют его
Конкретные целевые настройки: PSE iPhone переопределяет настройки проектов Base SDK
В Xcode вы всегда открываете проекты (или рабочие пространства, но не цели), и все цели, которые он содержит, могут быть созданы/запущены, но нет способа/определения построения проекта, поэтому для каждого проекта требуется хотя бы одна цель чтобы быть не просто набором файлов и настроек.
Выберите одну из целей проекта для запуска
Во многих случаях проекты - это все, что вам нужно. Если у вас есть зависимость, которую вы создаете из исходного кода, вы можете встроить ее в подпроект. Подпроекты могут быть открыты отдельно или в рамках своего суперпроекта.
demoLib - это подпроект
Если вы добавите одну из целевых подпроектов к зависимостям суперпроектов, подпроект будет автоматически построен, если он не останется без изменений. Преимущество здесь в том, что вы можете редактировать файлы как из своего проекта, так и из ваших зависимостей в одном окне Xcode, а когда вы создаете/запускаете, вы можете выбрать из проектов и целей его подпроектов:
Если, однако, ваша библиотека (подпроект) используется множеством других проектов (или их целей, если быть точным), имеет смысл поставить ее на один и тот же уровень иерархии - вот что workspaces для. Рабочие пространства содержат и управляют проектами, и все проекты, которые он включает напрямую (т.е. Не их подпроекты), находятся на одном уровне, и их цели могут зависеть друг от друга (цели проектов могут зависеть от целей подпроектов, но не наоборот).
Структура рабочего пространства
В этом примере оба приложения (AnotherApplication/ProjectStructureExample) могут ссылаться на цели проектов demoLib. Это также было бы возможно, включив проект demoLib в оба других проекта в качестве подпроекта (который является только ссылкой, поэтому не требуется дублирования), но если у вас много перекрестных зависимостей, рабочие пространства имеют больше смысла. Если вы откроете рабочее пространство, вы можете выбрать из всех целей проекта при построении/запуске.
Вы все равно можете открывать файлы проекта отдельно, но, скорее всего, их цели не будут созданы, потому что Xcode не может разрешить зависимости, если вы не откроете файл рабочей области. Рабочие пространства дают вам такое же преимущество, как и подпроекты: после изменения зависимости Xcode перестраивает его, чтобы убедиться в его обновлении (хотя у меня были некоторые проблемы с этим, он, похоже, не работает надежно).
Ваши вопросы в двух словах:
1) Проекты содержат файлы (код/resouces), настройки и целевые объекты, которые создают продукты из этих файлов и настроек. Рабочие области содержат проекты, которые могут ссылаться друг на друга.
2) Оба отвечают за структурирование вашего общего проекта, но на разных уровнях.
3) Я думаю, что проектов достаточно в большинстве случаев. Не используйте рабочие пространства, если только не существует конкретной причины. Кроме того, вы можете вставлять свой проект в рабочее пространство позже.
4) Я думаю, что это текст выше...
Это одно замечание для 3): CocoaPods, которое автоматически обрабатывает сторонние библиотеки для вас, использует рабочие области. Поэтому вы также должны использовать их, когда используете CocoaPods (что много людей).
Рабочее пространство представляет собой набор проектов. Полезно организовать ваши проекты, когда есть корреляция между ними (например: Project A включает библиотеку, которая предоставляется в качестве самого проекта в качестве проекта B. Когда вы строите проект рабочей области, B компилируется и связывается в проекте A).
Обычно используется рабочее пространство в популярном CocoaPods. Когда вы устанавливаете свои контейнеры, они размещаются внутри рабочей области, в которой хранятся ваши проекты и библиотеки модулей.
Вкратце
Когда я использовал CocoaPods для разработки проектов iOS, есть файл .xcworkspace, вам нужно открыть проект с файлом .xcworkspace связанным с CocoaPods.
Но когда вы Show Package Contents с файлом .xcworkspace, вы найдете файл contents.xcworkspacedata.
<?xml version="1.0" encoding="UTF-8"?> <Workspace version = "1.0"> <FileRef location = "group:BluetoothColorLamp24G.xcodeproj"> </FileRef> <FileRef location = "group:Pods/Pods.xcodeproj"> </FileRef> </Workspace>
обратите внимание на эту строку:
location = "group:BluetoothColorLamp24G.xcodeproj"
Файл .xcworkspace имеет ссылку с файлом .xcodeproj.
Среда разработки: macOS 10.14 Xcode 10.1
Первым был Project, который определяет ваш исходный код, ресурсы и как работать с ним (настройки, сборка, тестирование...) через targets и schemes. Project позволяет вам создать простой пример, но что делать, если вам нужно использовать другие источники проекта внутри - dependency?
Xcode 3 представил cross-project references[About], который позволяет добавлять подпроект. Это тип Explicit dependency, и он имеет только видимость области проекта. Иногда работать с таким типом зависимости неудобно, и вы можете столкнуться с
Не удалось загрузить Project.xcodeproj, поскольку он уже открыт из другого проекта или рабочей области
Xcode 4 представил Workspace для проведения одного или нескольких проектов. Проект может принадлежать более чем одному рабочему пространству. Наряду с этим появляется Implicit dependency[About]. Имеет видимость workspace. Например, CocoaPods[About] использует этот подход для создания двоичного файла.