Избегайте компиляции накладных расходов

Question

Я работаю над проектом SpiderMonkey, который представляет собой крупномасштабный проект с большим количеством файлов .h и .cpp. Несмотря на то, что я знаю, что я изменил только файл или два файла, каждый раз, когда я делаю изменения в проекте, мне нужно запустить команду make и снова скомпилировать весь проект, чтобы получить исполняемый файл ./js.

Итак, мой вопрос в том, есть ли решение избежать компиляции всех файлов и скомпилировать только определенные файлы, чтобы получить новый исполняемый файл ./js?

Answer 1

make утилиты имеет смысл мишеней и зависимости. Target только перестроен, если есть Зависимость изменена, в противном случае считается актуальной (немного упрощенное объяснение). Следующий Makefile заставит цель быть восстановлена, только если какой-либо файл объекта изменяется, и объектный файл будет восстановлен, только если источник/заголовок изменен:

all: target 

target: obj1.o obj2.o 
    $(CC) -o $@ $^ 

obj1.o: obj1.c obj1.h 
    $(CC) -o $@ -c $< 

obj2.o: obj2.c obj2.h 
    $(CC) -o $@ -c $< 

Сказав, что, вероятно, следует рассмотреть Makefile и проверку проекта если зависимости определены правильно. Сложные системы сборки (например, autotools/automake) используют $ (CC) -M или -MM для создания списка зависимостей для источников.

P.S. Убедитесь, что даты источника/заголовка файлов верны, а не в будущем. make обычно вызывает предупреждение в этом случае, поскольку он не может правильно определить изменения зависимостей. Это может быть особенно важно для файлов NFS, которые редактируются на одном компьютере и скомпилированы на другом.

Answer 2

Вы можете попробовать изменить только файлы cpp, а не h, потому что файлы cpp включают один раз в проекты. Также вы можете использовать директиву #pragma once, некоторые компиляторы имеют ускорение компиляции. И все же вы можете использовать инструмент IncrediBuild в своей компании. Он распространяет компиляцию на всех компьютерах, где есть IncrediBuild.

Answer 3

Вся идея заключается в make заново построены только те части проекта, нужно восстановления, судили по датам модификации файлов и информации о зависимости доступной make.

Если ваш проект займет много времени, чтобы перекомпилировать, есть три вещи, которые могут быть виноваты:

1. Информация зависимость доступна make не является оптимальным, то есть make перекомпилирует файлы, которые не требуют перекомпиляции, потому что он думает, что есть зависимости, где их нет. Это был бы дефект Makefile, то есть плохой дизайн Makefile.

2. Существует множество зависимостей. Файлы реализации, включая множество заголовков, заголовков, включая друг друга и т. Д. И т. Д. - вы получаете одну небольшую модификацию, требующую перекомпиляции множества единиц перевода (обычно при редактировании файла заголовка). Это будет архитектурным недостатком рассматриваемого проекта и может быть исправлено только с помощью основного рефакторинга.

3. Проект предполагает использование предварительно скомпилированных заголовков. Обычно это приводит к созданию одного очень большого файла заголовка (или заголовка, содержащего множество других), который затем сохраняется в предварительно обработанной форме.В том числе это предварительно обработанный заголовок - очень дешевая операция, но если ваша настройка фактически не do этот вид предварительной обработки (но включает в себя монолитный заголовок как есть), время компиляции может увеличиться. Это будет недостатком вашей установки; проверьте доступную документацию и свою настройку.

Который один отвечает за вашей конкретной проблемы? На самом деле я не могу сказать. (Я не знаю в первую очередь о Spidermonkey.)

Answer 4

Учитывая, что установленный проект SpiderMonkey, по-видимому, содержит хороших разработчиков, вероятно, make-файл в основном звучит с относительно небольшим количеством поддельных зависимостей. Если это неверно, вы можете запросить сообщество SpiderMonkey о том, почему изменения в конкретном файле инициируют перестройку какого-либо другого или работают на уровне кода, чтобы узнать, что использует зависимый файл (возможно, выборочно удаляя #include s чтобы увидеть, какие перерывы).

Тем не менее, вполне возможно, что вы изменяете файлы, которые содержат множество подлинных зависимостей, таких как заголовочные файлы, включенные (прямо или косвенно) множеством разных единиц перевода. Если это так, то относительно мало можно обойтись без реструктуризации кода. Методы, которые могут помочь включить определения функций вне линии, заголовки декларации вперед (ala the Standard's <iosfwd>), идиома pImpl, используя виртуальные интерфейсы, и не будут полностью удовлетворены шаблонами (поскольку определения должны быть включены кодом клиента в Работа).