> сравнивают скорее всегоНет. Если они и хитрят, то с выбором железа для сборки.
> сборка занимает по времени много больше.
GTK сваян на C. Компиляторы C просто реактивные, по сравнению с некоторыми. При этом, в отличие от configure, процесс собственно компиляции отлично ускоряется увеличением числа ядер. А вот ./configure будет тормозить на 8-ядерном процессоре ровно так же, как он тормозил на одноядерном. Если в проекте несколько скриптов ./configure, то каждый из них будет тормозить, и делать они это будут по-очереди, занимая ровно одно ядро.
Ещё интереснее, когда distcc используешь, чтобы собирать свою генту в офисе, где удалось тихим вечерком два десятка офисных компов в сборочный кластер собрать, чтобы по-бырому раскатать дженту на не очень шустром ноуте. Там этот configure начинает откровенно выбешивать. Вообще складывается ощущение, что вся сборка состоит из бесконечных вызовов ./configure и бесконечных проверок того, что char занимает 1 байт, "может что изменилось с предыдущего раза и char подрос?". Весь этот вывод configure уже заучен наизусть, я его сам могу на клавиатуре набрать с закрытыми глазами, ан нет, автотулзы продолжают долбить в одну и ту же точку.
А, и да, я отмечу, что так бесили они меня более десяти лет назад, и те два десятка офисных компов были селерончиками в которых, если мне память не изменяет, стояли смешные 256Mb оперативки. Что будет сейчас, если это не селерончики, а какие-нибудь двух-четырёх ядерные монстры, я вообще с трудом представляю. Секунд десять думает emerge, потом ещё тридцать секунд configure, после чего пять секунд компиляции, две секунды линковки, и ещё секунд десять на emerge. Что-нибудь в этом стиле. Реально погреться такому кластеру удастся только на всяких там файрфоксах да опенофисах.
