Ускорение сборок C ++ с Unity Builds и уменьшенными зависимостями заголовка - PullRequest
0 голосов
/ 20 сентября 2018

Я только что преобразовал проект Objective-C (++) в простой C ++.Перемещая все больше и больше кода, я заметил, что время сборки значительно увеличилось.

Мой проект в настоящее время разделен на несколько фреймворков / dylibs и основной проект, использующий эти фреймворки.

Я провел некоторое исследование и обнаружил, что в основном рекомендуется сократить время сборки на три вещи:

  • уменьшение зависимостей заголовка
  • при использовании единственных сборок
  • с использованием такого инструмента, какccache, чтобы не повторять ненужную работу все время

Я реализовал ccache, и он прекрасно работает, и мне удалось немного сократить время сборки.

Я немного не уверен насчет уменьшения зависимостей заголовка и построения единиц.Я читал, что большой недостаток Unity builds заключается в том, что вам нужно перекомпилировать все, если вы вносите изменения в один исходный файл, что имеет смысл.Однако это не будет проблемой для фреймворков, так как в любом случае их придется перекомпилировать, если они изменятся.

Я читал, что это плохая практика - использовать "зонтичные заголовки", такие как "MyFramework.h", который будет включатьвсе публичные заголовки данного фреймворка, хотя вам может понадобиться только несколько из них.

Какао везде использует зонтичные заголовки, и это, конечно, намного проще, чем выбирать точные заголовки, необходимые для каждого исходного файла.Тем не менее, при использовании юнит-сборок у меня будет только один заголовок на каждый фреймворк, правильно?

Имеет ли смысл выбирать отдельные заголовки, или использование "зонтичных заголовков" будет в порядке со сборками юнитов?

Нажмите здесь, в темноте, и не хотите тратить время на реализацию техники, которая в конечном итоге не поможет.

Спасибо за вашу помощь!

1 Ответ

0 голосов
/ 20 сентября 2018

Это похоже на вопрос для взвешенных ответов.Мои таковы:

Всегда уменьшайте зависимости заголовка.Уменьшенные зависимости делают общую архитектуру более чистой.Независимые маленькие индивидуальные модули с четко распределенными обязанностями всегда лучше работать, чем спагетти.

Используйте предварительно скомпилированные заголовки для компиляции редко меняющихся заголовков.Заголовки зонтиков сторонних разработчиков, библиотек и фреймворков меняются редко, поэтому их тоже нужно редко анализировать и перекомпилировать.

Большую часть времени работайте с отдельными модулями (несколько файлов cpp) и модульными тестами для них.В противном случае вы создаете целую программу, затем переходите в нее к интересующей вас ситуации, затем добавляете туда отладчик и так далее.Может быть, вам это нравится, но я слишком ленив, это скучно повторяется и тратит впустую мое время.Только связывание всей программы на C ++ (чего угодно) обычно занимает десять и более минут, и мне не нужно так много перерывов на кофе.

Не используйте Unity builds, лучше используйте непрерывную интеграцию, которая, когда вы нажимаете, автоматически собирает и запускает все модульные тесты всей программы и готовит двоичные файлы на другом компьютере (или ферме).Вы получите уведомление, когда это будет сделано (или не удалось), а затем вы сможете взять двоичные файлы и отладить всю программу, если хотите.

...