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

Question

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

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

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

0

c++compiler-construction spidermonkey

Решение

Другие решения

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

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

2

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

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 для построения списка зависимостей для источников.

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

1

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

0

Источник

Accepted Answer

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

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

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

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

3