Xcode Workspace vs Nested Projects

Question

Xcode Workspace vs Nested Projects

Nie rozumiem wykorzystania przestrzeni roboczej Xcode do organizowania projektów z zależności od siebie. Na przykład widzę, że wielu programistów tworzy struktury przestrzeni roboczej, które wyglądają tak:

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

Jakie korzyści daje to? Jeśli ktoś otworzy bezpośrednio Projekt "App", czy nie będzie w stanie zbudować aplikacji? Musieliby zdawać sobie sprawę, że istnieje przestrzeń robocza z niezbędnymi zależnościami.

Wydaje mi się, że lepszym podejściem jest użycie zagnieżdżonych projektów TAK:

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

Wtedy nie istnieje projekt, który nie może być zbudowany. Wydaje się to również bardziej zgodne z ideą Gita podmodułów.

Jedynym zastosowaniem, jaki widzę dla obszaru roboczego, jest grupowanie wspólnych projektów bez zależności od siebie. Chciałbym usłyszeć opinie innych ludzi na ten temat, ponieważ mogę coś przeoczyć.

34

xcode code-organization project

Author: Josh Caswell, 2012-07-23

Source

2 answers

Dodaliśmy zagnieżdżone projekty do frameworków głównego projektu, więc mogliśmy je " włączyć "do.produkt ramowy.

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

Zobacz ten świetny samouczek autorstwa Jeffa Verkoeyena do dodawania uniwersalnych frameworków do projektu. Na początku nie jest łatwo, ale pracuj nad tym, a zrozumiesz.

1

Author: Patricia,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-08-19 20:44:57

score 17 · Accepted Answer

Używam przestrzeni roboczych, gdy chcę łączyć projekty, zachowując jednocześnie niezależność projektu.

Przykładem, w którym używam przestrzeni roboczych, jest seria projektów samouczków, które przechodzą od bardzo prostych do bardziej złożonych. Każdy projekt może funkcjonować jako samodzielny projekt, ale grupowanie ich razem w przestrzeni roboczej pomaga mi w organizacji całego projektu.

W innym przypadku mam aplikację opracowaną dla klienta. Aplikacja działa zarówno jako samodzielna aplikacja jak i moduł w ogólny projekt. Niezależny projekt może zbudować samodzielną aplikację. Druga aplikacja korzysta z obszaru roboczego, który obejmuje dwa projekty. Wersja modułu aplikacji jest zbudowana ze specjalnego schematu, a ta połączona aplikacja nie buduje się bez użycia obszaru roboczego.

Jedną z dwóch powyższych sytuacji jest to, że folder kompilacji jest przechowywany. Muszę zmienić preferencję Xcode umieścić produkty build w unikalnych folderach dla grupy projektów samouczek, użyj wspólnego folderu build dla moduł w innej konfiguracji aplikacji.

W innych okolicznościach mam mnóstwo projektów z wbudowanymi projektami. W takich sytuacjach projekty biblioteczne są stabilne. Nie podejmuję prób dalszego rozwoju projektów bibliotecznych, więc są one tylko kolejnym zasobem dla projektu. Łatwiej jest mi pracować tam, gdzie moja organizacja systemu plików zasobów projektu w pewnym stopniu odzwierciedla organizację mojego projektu Xcode. Więc te projekty bibliotek są kopiowane do pliku głównego projektu hierarchia. Używanie przestrzeni roboczych byłoby sensowne, gdybym rozwijał biblioteki i używał ich w wielu projektach. Dla wygody często nie zawracam sobie głowy.

Czasami nawet łączę przestrzenie robocze z projektami zawierającymi projekty wbudowane.

Moim zdaniem zarówno narzędzia organizacyjne, projekty wbudowane, jak i przestrzenie robocze mają swoje zalety i problemy. Wybieram użycie jednego lub drugiego (lub kombinacji) w zależności od szczególnych okoliczności.