Можно ли ускорить./configure?

Я вспоминаю обсуждения в списке рассылки Autoconf около 10 лет назад, когда у большинства людей было только одно ядро ​​процессора. Но ничего не было сделано, и я подозреваю, что ничего не будет сделано. Было бы очень сложно настроить все зависимости для параллельной обработки в configureи делать это таким образом, чтобы он был портативным и надежным.

В зависимости от вашего конкретного сценария, в любом случае может быть несколько способов ускорить запуск конфигурации. Например:

• Используйте более быструю оболочку. Например, рассмотрите возможность использования dash вместо bash как /bin/sh, (Примечание: в Debian dash залатано так что configure не использует его, потому что использование этого ломает много configure скрипты.)
• Если вы запускаете сборки удаленно (например, через ssh), я обнаружил, что вывод на консоль может быть довольно медленным. Рассмотреть вопрос о звонке configure -q,
• Если вы неоднократно собираете один и тот же проект, рассмотрите возможность использования файла кэша. Вызов configure -C, Подробности смотрите в документации Autoconf.
• Если вы создаете много разных проектов, подумайте об использовании файла сайта (config.site). Снова смотрите документацию.
• Постройте несколько проектов параллельно.

Есть много типов ./configure скрипты. Существуют популярные инструменты (одним из которых является autconf), помогающие разработчику в создании ./configure сценария, но не существует правила, которое гласит, что каждый разработчик должен использовать эти инструменты, и тогда даже среди этих инструментов могут быть широкие различия в способах построения этих сценариев.

Я не знаю ни одного популярного ./configure скрипты, которые можно запускать параллельно. Большинство сценариев, созданных популярными инструментами, по крайней мере кэшируют некоторые или все свои результаты, поэтому, если вы запустите его снова (без выполнения make clean во-первых, во втором случае он работает намного быстрее.

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

Вы умно использовали ramdrive для размещения исходного дерева, но дважды подумайте - что делает configure? Он выполняет свою работу, проверяя не только ваше исходное дерево, но довольно часто и систему на наличие библиотек, компиляторов и т. Д. В этом случае проблема доступа иногда заключается в доступе к диску - вы сделаете это намного быстрее, если Пример корневой файловой системы на основе SSD.

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

Поэтому просмотрите / прочитайте мои советы о том, как ускорить процесс, по адресу https://gitlab.com/gnuwget/wget2/wikis/Developer-hints:-Increasing-speed-of-GNU-toolchain.

"Почему нужно проводить тесты последовательно? ..." На самом деле есть несколько вещей, которые можно выполнять параллельно, в то время как другие должны быть последовательными. Несколько вещей зависят от среды сборки - и сам скрипт configure не зависит от системы. Он даже не содержит bashisms, поэтому он работает с чистой оболочкой POSIX.

Если вы хотите написать переносимое программное обеспечение, другой системы сборки, такой как autotools, не существует. Но если вы не возражаете против (широкой) переносимости, избегайте автоинструментов - существует множество быстрых и достаточно хороших инструментов для сборки.

В этом случае узким местом является жесткий диск. Чтобы ускорить сборку, соберите систему с быстрыми дисками (читай: малое время доступа). По поводу SSD-дисков много суеты, но была некоторая критика в отношении того, что они не влияют на время компиляции в позитивном ключе. То есть сборка на SSD была не намного быстрее, чем на приличном диске SATA. Я не могу вспомнить, где я читал это, потому что статье пару лет.

В любом случае... Унтар, чтобы таранить и строить оттуда.

mkdir /tmp/tmp 
mount -t tmpfs -o size=400M tmpfs /tmp/tmp 
cd /tmp/tmp
tar xjf somesourcetarball-1.1.33.tar.bz2

Если вы используете регулятор скорости процессора ondemand, попробуйте использовать производительность. Это помогает на i7 и a8-3850 на 40-50%. Не имеет большого значения на Q9300.

На четырехъядерном процессоре вы можете сделать

for cpu in `seq 0 3`; do sudo cpufreq-set -g performance -c $cpu; done

(Опция -r должна сделать так, чтобы вам не приходилось делать cpufreq-set для каждого ядра, но на моих компьютерах это не работает.)

Хотя опция кеша помогает еще больше.