Это из-за того, что за последние пару дней я получил значительное количество седых волос, пытаясь найти настройку, которая заставила бы текущую версию Xcode 4 превратить мои проекты iOS в неожиданный, но не незнакомый, перенесенный из Xcode. 3, местоположение, но не представляет какой-либо очевидный способ вернуть это.
Немного истории
В Xcode3 вы можете использовать диалог настроек для настройки пользовательских папок вывода сборки. Это было необходимо, когда вы хотели организовать несколько более сложное программное обеспечение в несколько проектов Xcode с перекрестными ссылками и в то же время сохранить некоторую здравомыслие при компоновке и упаковке.
Учебник Клинта Харриса по общим библиотекам описывает его более подробно.
Диалог настроек выглядел следующим образом (изображение скопировано с сайта Клинта, потому что у меня больше не было установки Xcode3):
В моей почтенной настройке Xcode 3 я настроил вывод для общей сборки в / Users / ds / Documents / cc / SharedBuildOutput.
Представляем Xcode 4
В марте 2011 года Apple выпустила Xcode4, капитальный ремонт среды IDE со множеством новых функций и, конечно же, новой конфигурацией. На момент написания этой статьи в январе 2012 года последний выпуск Xcode был 4.2.1, и я установил большинство выпусков в качестве обновлений на свой MacBook Pro. Диалог настроек местоположения сборки выглядит так в моей текущей установке:
Как вы можете видеть, нет никаких следов ранее настроенного параметра вывода общей сборки, не говоря уже о моем пользовательском каталоге.
Итак, по-видимому, это новый способ ведения дел, и, безусловно, будет применяться новый проект.
Не так быстро …
Несмотря на то, что (я для) можно было бы ожидать, тем не менее, это то, на что похожи фактические настройки сборки нового проекта (iOS) (я отфильтровал, чтобы просто показать соответствующие части):
Переключение с режима «
Комбинированный на
уровни» показывает, что параметр явно не исходит от самого проекта, что объясняет, почему даже недавно созданный проект мог знать об этой старой папке:
Это явно идет вразрез с текущим стандартом Xcode, заключающимся в размещении продуктов сборки в так называемых папках подпапок «Производные данные» со (частично) случайными именами. Сценарии сборки могут использовать их, ссылаясь на них с помощью переменных среды, но чаще всего оставление пути (теперь уже пройденного) новых значений по умолчанию вызовет больше проблем, чем обычно стоит.
«Как мне это исправить?», Спросите вы. Ну, я тоже об этом спрашивал, и мне потребовалось несколько дней, чтобы наконец понять это. Помните, что Xcode 4 больше не показывает этот путь в своих настройках Build Locations, так что это, очевидно, не продвигает нас дальше.
Обойдя проблему…
Изменение папки на уровне проекта работает, переопределяя настройки по умолчанию. Как только вы создали новый проект, вы можете изменить «Путь к проектам сборки» и «Путь к файлам промежуточных сборок» для простой сборки. Это должно быть то же значение, которое используется по умолчанию в новой установке Xcode 4.
Мне нравится хранить настройки моей сборки в отдельном файле .xcconfig, который позволяет обмениваться настройками с другими участниками проекта с помощью контроля версий. Если вы сделаете это, вы также можете использовать это для переопределения старого значения по умолчанию, поместив в него следующие строки:
SYMROOT = build OBJROOT = build
Однако это также требует от вас внесения изменений в каждый новый проект. Конечно, было бы лучше избавиться от этой нежелательной установки.
… или решить это
Хотя в Xcode 4 больше нет настроек предпочтений пользовательского интерфейса для изменения настроек SYMROOT и OBJROOT, очевидно, они все еще учитывают их из предыдущей установки Xcode 3. Поэтому для их сброса нам нужно знать, где они хранятся. Я не знал ничего, кроме того, что это должен быть пользовательский параметр, потому что вновь созданная учетная запись не использовала его. Итак, после удаления всего из ~ / Library / Developer / Xcode / DerivedData — я попытался (в следующем порядке):
$ grep -r SYMROOT ~/Library/Developer 2>/dev/null $ grep -r SYMROOT ~/Library/Application\ Support/Developer 2>/dev/null $ grep -r SYMROOT ~/Library/Preferences 2>/dev/null
Ну, на самом деле я сначала попытался найти Documents / cc / SharedBuildOutput, но это также соответствовало нескольким архивным приложениям. Последняя команда показала это:
Binary file ./com.apple.dt.Xcode.plist matches
Преобразование первого совпадения в XML с помощью plutil -convert xml1 -o tmp.xml com.apple.dt.Xcode.plist и поиск по нему я нашел так:
<key>IDEApplicationwideBuildSettings</key> <dict> ... <key>SYMROOT</key> <string>/Users/ds/Documents/cc/SharedBuildOutput</string> ... </dict>
Вместо того, чтобы удалить эти две строки и преобразовать файл обратно в его двоичный формат, я удалил эту запись с помощью небольшого
удобного приложения PrefSetter, перейдя в домен com.apple.dt.Xcode и выполнив там поиск
SYMROOT . Таким образом, нет риска сделать какие-либо опечатки, повредив файл.
Не забудьте сохранить изменения!
Успех!
Перезапуск Xcode и просмотр настроек сборки того же самого «Тестового» проекта, созданного ранее, доказывает, что изменение дало желаемый эффект:
Конечно, в крайнем случае (может быть, у вас больше проблем с настройками XCode?), Вы также можете просто удалить или переименовать файл com.apple.dt.Xcode.plist и запустить XCode заново, даже если я заметил когда я попробовал это, некоторые настройки остались без изменений, т.е. грамм. Исходные деревья. Они, очевидно, хранятся где-то еще …
С http://www.danielschneller.com/2012/01/removing-xcode-3-shared-build-settings.html