У меня довольно сложный скрипт, который компилирует большой проект C++.
На этой странице руководства gcc говорится:
Компилятор выполняет оптимизацию на основе знаний, которые он имеет в программе. Одновременная компиляция нескольких файлов в один выходной файл позволяет компилятору использовать информацию, полученную из всех файлов при компиляции каждого из них.
Поэтому лучше предоставить все мои файлы одному g++
и позволить ему управлять компиляцией, но это радует.
Но Скинсон этого не делает. он называет g++
отдельно для каждого отдельного файла C++ в проекте, а затем связывает их с помощью ld
Есть ли способ заставить SCons сделать это?
Основной причиной наличия системы сборки с возможностью выражения зависимостей является поддержка некоторой условной/инкрементной сборки. В противном случае вы можете просто использовать скрипт с одной командой, в которой вы нуждаетесь.
Это говорит о том, что результат оптимизации gcc/g++, как описано в руководстве, является существенным. В частности, если у вас есть C++ шаблоны, которые вы часто используете. Хорошо подходит для производительности во время исполнения, что плохо для производительности перекомпиляции.
Я предлагаю вам попробовать и сделать свой собственный строитель, делая то, что вам нужно. Вот еще один вопрос с вдохновляющим ответом: пользовательский построитель SCons - сборка с несколькими файлами и вывод одного файла
В настоящее время нет.
Логика, подобная этой, была разработана только для MSVC. Вы можете увидеть это на странице руководства (http://scons.org/doc/production/HTML/scons-man.html) следующим образом:
MSVC_BATCH Если установлено какое-либо истинное значение, указывает, что SCons должен выполнять компиляцию объектных файлов при вызове компилятора Microsoft Visual C/C++. Все компиляции исходных файлов из того же исходного каталога, которые генерируют целевые файлы в одном и том же каталоге вывода и которые были сконфигурированы в SCons с использованием той же строительной среды, будут созданы в одном вызове компилятору. Исходные файлы, которые были изменены с момента создания их объектных файлов, будут переданы каждому вызову компилятора (через переменную const $ CHANGED_SOURCES). Любые компиляции, в которых базовое имя файла объекта (цели) (минус.obj) не соответствуют базовому имени исходного файла, будут скомпилированы отдельно.
Как всегда патчи могут добавить это более общим образом.
В общем, это нужно оставить разработчику программы. Попытка скомпилировать все вместе в объединении может ввести непреднамеренное поведение в программу, если оно даже скомпилируется в первую очередь. Лучше всего, если вы хотите эту оптимизацию без редактирования исходного кода, это использовать компилятор с оптимизацией между процессами, например icc -ipo
.
Пример, когда объединение двух файлов .c
не будет компилироваться, например, если они используют два идентичных static
символа с разной функциональностью.
g++ filea.cpp fileb.cpp filec.cpp
вместо запуска g ++ 3 раза, по одному разу для каждого исходного файла. (А не, например, объединить все 3 файла в один исходный файл.)