|
ВведениеМного разработчиков редко изменяют проекты, которых они инстанцируют из шаблонов XCode. Тонкая настройка настроек проекта является отличным способом изучить XCode подробно. Кроме того, это - отличный способ применить оптимизацию к Вашим проектам, гарантируя, чтобы они создали максимально быстро. С этой целью вот некоторые простые подсказки, что можно примениться к проектам прямо сейчас для получения их создающий быстрее. Нормализуйте свои настройки сборкиПроекты и цели в XCode имеют При создании нового проекта из одного из шаблонов XCode основная цель в том проекте будет обычно иметь много настроек сборки настроенными в ее конфигурациях. Сам проект, с другой стороны, не будет иметь очень многих настроек сборки под заказчика. Для одной цели на случай проекта это не имеет значения очень. Однако при создании проекта с многократными целями можно завершить со многими целями, указывающими то же (или тонко отличающийся) информация. Вместо того, чтобы оставить Ваш проект этим путем, можно нормализовать настройки сборки, таким образом, что настройки сборки, которые Вы хотите указать для каждой цели в проекте — например, что компиляторная оптимизация должна быть выключена для Настройки отладочного процесса — указаны на уровне проекта, а не на целевом уровне. Это использует в своих интересах факт, что настройки сборки наследованы в XCode - если установка сборки не настраивается в цели, значение, указанное в проекте, используется. Примечание: Сборка, устанавливающая, которому очистил значение пользователь, является установкой сборки под заказчика. Несмотря на то, что это не содержит текущей стоимости, действие изменения значения изменяет установку. Это отличается, чем сборка, устанавливающая, который никогда не настраивался. Это - важное понятие как обработки системы сборки XCode настройки настроенной и несборки под заказчика по-другому. Что это покупает Вас? Это гарантирует, чтобы у Вас был единственный, непротиворечивый набор настроек, передающихся компиляторам, компоновщикам и другим инструментам, использующимся для создания программного обеспечения. Поэтому Вы избежите тонких ошибок как код, созданный с Совместно используйте свои предварительно скомпилированные префиксные файлыXCode, как много других IDEs, поддерживает префиксные файлы — заголовочные файлы, включенные неявно каждыми из Ваших исходных файлов, когда они создаются. Обычно эти файлы указаны в каждой из целевых настроек сборки Вашего проекта. Текст в префиксном файле, копирующемся из шаблонов XCode даже, упоминает, что это связано с определенной целью. Однако возможно совместно использовать префиксные файлы в Вашем проекте. Префиксные файлы предварительно компилируются для производительности, таким образом, они могут просто быть загружены компилятором, а не повторно вычислены для каждого файла, Вы создаете. Предварительная компиляция префиксного файла занимает довольно мало времени, хотя, особенно при использовании многократных языков в проекте (таких как C, Objective C и C++), потому что каждому языку нужен отдельный предварительно скомпилированный префикс вследствие различий в том, как они обработают «тот же» код. Однако просто, потому что предварительно скомпилированные префиксные файлы не могут быть совместно использованы языками, не означает, что они не могут быть совместно использованы целями. Фактически, для производительности, XCode автоматизирует это совместное использование для Вас — при встрече его на полпути. Критическая вещь, которую необходимо сделать, состоит в том, чтобы гарантировать, что префиксные файлы:
Эти критерии могут быть легко удовлетворены путем нормализации настроек сборки для целей на уровне проекта. Можно даже продвинуть префиксный файл, для которого предназначаются связанные настройки сборки к настройкам проекта вместо в каждом. Это гарантирует, чтобы они совместно использовали то же имя. Фактически, если они удовлетворяют критерии, что использование XCode, чтобы определить, должны ли предварительно скомпилированные префиксные файлы быть совместно использованы, даже многократные проекты, завершит совместное использование их! Пауза между сборками зависимых целей цели для генерации нового предварительно скомпилированного префиксного файла походит на останов конвейерной обработки: нежелательное отклонение, содержащее все остальное вплоть до него, закончено. Если XCode может предварительно скомпилировать единственный набор префиксных файлов в начале Вашей сборки и затем снова использовать их для остальной части процесса, это передаст потоком мимо как можно быстрее с только случайной паузой для соединения. Поскольку крупные проекты со многим зависимым предназначаются, это может иметь большое значение во время завершения сборки. Разделите свои макросы препроцессораДругой метод оптимизации должен указать отдельные макросы препроцессора для Ваших префиксных файлов и целей. Это работает, даже когда Ваш проект имеет целевые макросы препроцессора - пока Вам не нужны они в Ваших префиксных файлах, можно установить их в Конечно, существуют макросы, которые Вы действительно хотите установить в Ваших предварительно скомпилированных префиксных заголовках, потому что они изменяют поведение. Макросы как Дополнительное чтениеВ то время как этот документ попробовал пастуху Вашему посредством процесса ускорения Вашей производительности сборки проекта XCode, были понятия, представленные это, можно хотеть исследовать далее. Вот некоторые ссылки к полезной документации, которая объяснит подробно анатомию проектов XCode, как работать с системой настроек сборки XCode и работающий с предварительно скомпилированными префиксными заголовками. История версии документа
| ||||||||||
