можно ли распараллелить make?

checking for

Это autotools что ли?

да. если проект большой, например buildroot - то компилишь 30% времени а 70% ждёшь, пока однопоточный конфигуратор «тупит» - видно что пока все эти миллиарды «checking for sanity/insanity...» происходят - задействовано только одно ядро :) как лечить?

Никак (без переписывания autotools).

Использовать CMake. Впрочем, эскобар.жпг

Кэш конфига. Ноэтонеточно.

такие перспективы печалят меня.. что неужели за всё это время с появлением многоядерных процессоров никто не задумался о распараллеливании этого дела?

посчитайте мне сколько будет 2+x при условии что x вы не знаете ?
конфигураторов линейная логика, каждое выражение выводится из результатов предыдущего, это нельзя распараллелить
в компиляции, настройка конфигов это 1-3% времени, и оно не существенно

Используйте нормальные системы сборки, а не говно мамонта.

make к конфигурации не имеет никакого отношения

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

покажи мне «нормальные системы», умеющие в распараллеливание процесса конфигурации

Брысь.

Слив засчитан! :)

Выкинь автолулзы. Это единственный способ.

autismtools никак не исправить.

Вы смешали всё в одну кучу. configure это одно, make - другое. Нет, configure нельзя распараллелить, ибо это autocrap. Да обычно и не нужно, я не припомню проектов где оно выполнялось бы дольше десятка секунд. Конечно же оно несоизмеримо со временем компиляции сколь либо крупного проекта.

Используйте нормальные системы сборки, а не говно мамонта.

это про тупящий cmake ? так он также при конфигурации работает. это не возможно расспраралелить просто.

а с учетом того что cmake не проверяет вообще ничего, так и говорить нечего, ну да, стильно модно молодежно.

посчитайте мне сколько будет 2+x при условии что x вы не знаете ?

Пока точное значение не нужно, можно считать что ответ y. Причем y = 2+x (или y = f(x))

да ну ? ну тогда вам и автоконфг запускать не нужно, он то считай результат выводит и не формулы упрощает

да ну ?

https://en.m.wikipedia.org/wiki/Lazy_evaluation

да. если проект большой, например buildroot - то компилишь 30% времени а 70% ждёшь, пока однопоточный конфигуратор «тупит»

Лучше всего, конечно, один раз сделать configure, а потом пересобирать с готовой конфигурацией. Или там Makefile вызывает configure каждый раз?

покажи мне «нормальные системы»

Сейчас вполне себе нормальным является meson. Распараллеливания конфигурации там тоже нет, НЯЗ, но работает шустро.

даже если указываю -j
например buildroot

На первых страницах документации

Buildroot quick start
You should never use make -jN with Buildroot: top-level parallel make is currently not supported.

то компилишь 30% времени а 70% ждёшь

Ну это ты преувеличиваешь. Возможно ты включаешь сюда время скачивания пакетов.

Хотя вопрос остается. Даже make source он выполняет последовательно. А с учетом того, что иногда используются тормозные зеркала (больше касается стронних сборок builroot-а), это жесть.

Наверное можно, разобравшись в выхлопе make graph-depends, запустить несколько make <pkg>-build для независимых пакетов (я не пробовал).

то есть вы можете про оптимизировать автоконф для параллельного выполнения ? ждем от вас результатов

разобравшись в выхлопе make graph-depends

Какая-то лажа в этом выхлопе :(
Из него следует, что toolchain нужен, просто потому, что нужен.

то есть вы можете про оптимизировать автоконф для параллельного выполнения ?

Могу

ждем от вас результатов

ждем от вас аванса.

Meson попробуй.

Распараллеливания конфигурации там тоже нет, НЯЗ, но работает шустро.

Оно там и не нужно, там конфигурация делается молниеносно, это же не aut*crap с его кучей проверок из прошлого века вроде:

checking for memcpy() in string.h...
checking for sin() in math.h...
checking for benis() in vagina.h...

Которые только диск насилуют. Плюс ещё всякие припарки, вроде libtool и т. д.

как можно ускорить

--config-cache, например.

эти все проверки туда люди руками зачем-то напихали, автотулз не принуждает проверять наличие memcpy и пениса в вагине