Как оптимизировать время запуска сценария SCons?

scons md5-sums файлы, чтобы выяснить, что они изменились, поэтому md5 суммирует все ваши файлы.

Вы можете указать ему использовать только временные метки, чтобы решить, что восстанавливать, а не приходится каждый раз суммировать все файлы по MD5, как это делает make, что должно ускорить процесс. Может быть, более хрупкий. например, если файл был изменен в течение 1 секунды после последнего создания, scons этого не заметит. Используйте

env.Decider('timestamp-newer')

Также есть MD5-timestamp, который сначала проверяет временную метку, а затем сравнивает контент с помощью Md5, если он действительно изменился, если временная метка более новая.

env.Decider('MD5-timestamp')

Еще один простой способ ускорить процесс - запустить параллельное построение с помощью Параметр -j.

scons -j 2

На моем 2-ядерном компьютере -j 3 обычно дает наибольшее ускорение.

(Похищено прямо с http://www.scons.org/wiki/GoFastButton )

Команда 'scons --max-drift = 1 - implicit-deps-unchanged 'выполнит вашу сборку как можно быстрее.

ИЛИ:

• env.Decider (' MD5-timestamp '): с SCons 0.98 вы можете установить функцию Decider в среде. MD5-timestamp говорит, что если временная метка совпадает, не беспокойтесь о повторном MD5-изменении файла. Это может дать огромное ускорение. См. Справочную страницу для информации.
• - max-drift: по умолчанию SCons будет вычислять контрольную сумму MD5 для каждого исходного файла в вашей сборке при каждом запуске и кэшировать контрольную сумму только после того, как файлу исполнилось 2 дня. . Это значение по умолчанию, равное 2 дням, предназначено для защиты от отклонения часов от NFS или систем контроля версий. Вы можете настроить эту задержку, используя --max-drift = SECONDS, где SECONDS - некоторое количество секунд. Уменьшение СЕКУНД может повысить скорость сборки за счет исключения излишних вычислений контрольной суммы MD5. Вместо того, чтобы указывать это в командной строке при каждом запуске, вы можете установить эту опцию внутри файла SConstruct или SConscript, используя «SetOption ('max_drift', SECONDS)».
• - implicit-deps-unchanged: по умолчанию SCons будет повторно сканировать все исходные файлы для неявных зависимостей (например, заголовок C / C ++ #includes), что может быть дорогостоящим процессом. Вы можете указать SCons кэшировать неявные зависимости между вызовами, используя параметр --implicit-deps-unchanged. Используя эти параметры, вы даете SCons обещание, что вы не изменили никаких неявных зависимостей с момента последнего запуска. Если вы измените неявные зависимости, то использование --implicit-deps-changed приведет к их повторному сканированию и кешированию. (Вы не можете установить эту опцию из файлов SConstruct или SConscript.)
• - implicit-cache: эта опция указывает SCons интеллектуально кэшировать неявные зависимости. Он пытается определить, изменились ли неявные зависимости с момента последней сборки, и если да, он пересчитает их. Обычно это медленнее, чем использование --implicit-deps-unchanged, но также более точное. Вместо того, чтобы указывать это в командной строке при каждом запуске, вы можете установить эту опцию внутри файла SConstruct или SConscript, используя «SetOption ('implicit_cache', 1)».
• CPPPATH: обычно вы сообщаете Scons о подключаемых каталогах, устанавливая CPPPATH конструкционная переменная, которая заставляет SCons выполнять поиск в этих каталогах при выполнении неявного сканирования зависимостей, а также включает эти каталоги в командную строку компиляции. Если у вас есть файлы заголовков, которые никогда или редко меняются (например, системные заголовки или заголовки времени выполнения C), вы можете исключить их из CPPPATH и вместо этого включить их в конструктивную переменную CCFLAGS, что заставляет SCons игнорировать эти подключаемые каталоги при сканировании. для неявных зависимостей. Тщательная настройка подключаемых каталогов таким образом обычно может привести к резкому увеличению скорости с очень небольшой потерей точности.
• Избегайте сканирования RCS и SCCS с помощью env.SourceCode (".", None) - это особенно интересно, если вы используют много заголовков c или c ++ в вашей программе и что ваша файловая система является удаленной (nfs, samba).
• При использовании "BuildDir" используйте его с "duplicate", установленным на 0: "BuildDir (dir1, dir2, duplicate = 0 ". Это заставит scons вызывать Builders, используя имена путей к исходным файлам в src_dir и имена путей к производным файлам в build_dir. Однако это может вызвать проблемы сборки, если исходные файлы генерируются во время сборки, если какие-либо вызываемые инструменты жестко запрограммированы для помещения производных файлов в тот же каталог, что и исходные файлы.
• На многопроцессорной машине это может быть полезно для одновременного выполнения нескольких заданий - используйте --jobs N (где N - количество процессоров на вашем компьютере) или «SetOption ('num_jobs', N)» внутри SConstruct или SConscript. На компьютерах с Windows количество процессоров доступно в переменной окружения 'NUMBER_OF_PROCESSORS'.
• Если у вас более нескольких десятков определений препроцессора ("-DFOO1 -DFOO2" ) вы можете обнаружить, используя --profile, что SCons много времени проводит в функции subst (), обычно просто добавляя строку -D к определениям снова и снова. Это действительно может замедлить сборку, в которой ничего не изменилось. С более чем 100 определениями я заметил, что время сборки без действий упало с 35 до 20 с, используя идею, описанную в разделе «Кэширование CPPDEFINES» на этой странице.

Еще одна уловка для ускорения работы - избегать повторного связывания программ, когда общая библиотека была изменена, но не перестроена. См. SharedLibrarySignatureOverride