При любом изменении кода (хотя файл не в формате .pch) полный проект каждый раз перекомпилируется.
При любом изменении кода (хотя файл не в формате .pch) полный проект каждый раз перекомпилируется.
Ответы:
Обновление 2017/1/2
Эта проблема не решена в Xcode 8.2.1 (для моего проекта)
Как выжить?
Code IDE: Xcode/Atom
Build: xcrun
Debug: Xcode (Control + Command + R)
Обновление 2016/12/17
Эта проблема не была решена в Xcode 8.2.
Обновление 2016/12/12
Теперь мой выбор - это атом для кода и командная строка для сборки и отладки. Надеюсь, Apple скоро исправит эту ошибку.
Обновление 2016/12/04
Эта проблема, похоже, решена в Xcode 8.2 (бета 2) .
Но для меня это не решено, я сталкиваюсь с этой проблемой, даже когда использую Xcode 8.2. Вы можете попробовать (скачать Xcode8.2 beta2 здесь )
Система сборки • Xcode не будет перестраивать всю цель, если произошли только небольшие изменения. (28892475)
Старый ответ: это работа:
Вкладка «Настройка сборки» -> «Диалект языка C» -> Измените его на «По умолчанию для компилятора».
«Диалект языка C» был установлен на «GNU99» вместо «Compiler Default». Раньше стандартом был GNU99, но теперь его нет. В какой-то момент Xcode не смог правильно перенести настройки проекта библиотеки, поэтому было установлено значение GNU99. Как только я изменил его на GNU99, он перестал каждый раз перекомпилировать весь мой код!
Перейдите в Продукт -> Схема -> Изменить схему. Выберите "Сборка" в левом столбце и снимите флажок " Найти неявные зависимости ".
Но этот флаг должен оставаться установленным, когда вы строите проект впервые.
Исправление для меня заключалось в закрытии раскадровки, у меня был открыт исходный файл с помощью вспомогательного редактора, а также был открыт файл раскадровки (закрытие раскадровки --- поскольку я не вносил в нее никаких изменений) удалил все ненужные компиляции
ОБНОВЛЕНО
Единственное самое большое улучшение, которое мне удалось сделать, - это модульное построение моего проекта. В частности, модулирование уровня ORM, который используется почти во всех других классах. Переместив этот код в отдельную цель в моем проекте и импортировав его как модуль, я смог значительно сократить время компиляции. Xcode больше не решает перекомпилировать ненужные файлы, когда я делаю сборку.
Теперь я использую метод компиляции одного файла для быстрой инкрементальной отладочной сборки.
В этой ссылке есть еще несколько хороших предложений, включая рефакторинг кода, https://medium.com/rocket-fuel/optimizing-build-times-in-swift-4-dc493b1cc5f5
OLD
Для меня все еще была постоянная проблема с Xcode 9. Как и многие из вас, я работаю над большим проектом Swift 4 / cocoapods со множеством исходных файлов, и каждый раз заново компилировать каждый файл, это бесит.
Пока что я получаю наилучшие результаты со следующими настройками. Я предлагаю вам попробовать и посмотреть, как это сработает для вас.
Добавлены пользовательские настройки сборки, определяемые пользователем,
Примечание. У меня нет настраиваемой пользовательской настройки для оптимизации всего модуля.
Я изменил в своем коде несколько вещей, касающихся заголовка префикса, которые, похоже, устранили эту проблему. Я не знаю, какой именно трюк сработал, но я поделюсь ими всеми в надежде, что это поможет кому-то еще. Если у вас нет набора заголовков префикса, то я думаю, это не проблема (или проблема многогранна).
@import MyModule
). (Для меня это и шаг 1 были одним и тем же.)Если это по-прежнему не работает, вы можете попробовать удалить еще несколько импортированных файлов из заголовка префикса. Может быть что-то его сбивает ...
Похоже, они активно работают над этим в соответствии с https://forums.developer.apple.com/thread/62737, но обходной путь - добавить
HEADERMAP_USES_VFS = YES
в настройках сборки вашей цели (Project -> Target -> Build Settings -> User Defined).
Это решение работало для меня каждый раз сегодня, после того, как ни одно другое решение не работало стабильно в течение последнего месяца.
РЕДАКТИРОВАТЬ: все еще иногда перекомпилируйте все, хотя, похоже, это делается гораздо реже с этим определенным параметром.
Проверяйте весь свой код в @IBDesignable
директивах в моем конкретном случае проекта сборки Xcode все время, потому что у меня было несколько представлений на моей раскадровке, которые содержали в себе эти @IBDesignable
атрибуты. Во-вторых, моя раскадровка открыта в отдельном окне (а не на вкладке), что навсегда заставляет мои сборки Xcode делать сборки для всех симуляторов.
@IBDesignable
директив ... есть ли что-то особенное, что мы должны искать?
Мадхури Мане в этом совершенно прав. Чтобы добавить немного большей ясности, обратите внимание на некоторые важные моменты:
Это применимо ТОЛЬКО, если у вас есть неявная зависимость от библиотек / фреймворков, на которые опирается ваша цель.
Если "Найти неявные зависимости" отключен:
Результат: библиотека не будет создана до создания целевого приложения. Целевое приложение не может быть построено.
Исправление: чтобы гарантировать, что второй сценарий не произойдет, вы должны добавить необходимые цели в список целей и правильно расположить их.
Источник и дополнительная литература по теме: https://pewpewthespells.com/blog/managing_xcode.html#scheme-action
Теперь, если весь ваш проект размещен в одной цели и компиляция занимает 4 минуты, вы ничего не можете с этим поделать, кроме как разбить его на фреймворки, чтобы воспользоваться вышеуказанным или выяснить, где происходит задержка компиляции. Если вы используете что-то вроде PaintCode или у вас есть большие фрагменты кода UIKit, быстро измените его на Objective-c, он компилируется намного быстрее
Apple выпустила новую бета-версию Xcode вчера (14 ноября)
Xcode 8.2 beta 2
В примечании к выпуску эта проблема отмечена как решенная.
Система сборки
• Xcode не будет перестраивать всю цель, если произошли только небольшие изменения. (28892475)
Это работает для меня. Скорость сборки вернулась как обычно. Всем, кто сталкивается с этой проблемой, стоит попробовать!
Пожалуйста, перейдите к настройкам сборки проекта и измените «Диалект языка Си».
"Диалект языка C" установлен на "GNU99" вместо "Compiler Default" при обновлении версии xcode. В какой-то момент Xcode не смог правильно перенести настройки проекта библиотеки, поэтому было установлено значение GNU99. Это решит проблему
Если вы внесли изменения в файл Swift, начните сборку приложения, перейдите на последнюю вкладку и щелкните журнал сборки, на этапе «Проверка зависимостей» остановите сборку и запустите ее снова. При втором запуске он должен собрать только те файлы, которые вы изменили. Если все сделано правильно, я обнаружил, что он работает каждый раз. Нет необходимости вносить какие-либо изменения в настройки проекта.
Похоже, это ошибка в Xcode.
Если вы видите, что приложение выполняет полную сборку, остановите сборку и попробуйте этот трюк еще раз.
Если вы не внесли изменений в код, используйте CMD + CTRL + R для запуска без создания приложения, которое подключает отладчик. Не будет создавать приложение, но поможет сэкономить ненужное время.
Проблема с моей стороны исправлена снятием флажка с решения «Найти неявные зависимости».
НО помните, если вы используете cocoapods, чтобы применить эти настройки также к вашему проекту pod, выбрав его из
Продукт -> Схема -> Пакеты- "yourProjectName"
также применяются в:
Продукт -> Схема -> "yourProjectName"
Это поможет мне, так что я надеюсь, что этот совет поможет кому-то другому.
Спасибо
Попробуйте: 1. Перейдите к проекту 2. Щелкните "Параметры сборки". 3. Убедитесь, что для параметра OptimizationLevel установлено значение "Нет" для отладки. 4. Щелкните Добавить пользовательскую настройку. 5. Установите для SWIFT_WHOLE_MODULE_OPTIMIZATION значение ДА.
Чтобы увеличить время компиляции xcode, можно использовать IRAMDISK (виртуальный диск памяти). Очень полезное и эффективное средство для сокращения времени компиляции.
Также можно использовать для ускорения часто используемых приложений.
обратитесь по следующей ссылке для загрузки и использования: http://iramdisk.findmysoft.com/mac/