Сегодня попробовал задать мейку во сколько потоков ему работать, т.к. у меня в системе видятся 4 ядра (1+HT)*2 то я задал 4:

Результат: проект собрался ровно в 2 раза быстрее!

Спешу поделиться своей радостью со всеми:-)

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

Спасибо за наводку!
Проверил, у меня видимо не такой большой проект...
При дальнейшем увеличении потов скорость сборки не изменяется, как была 18 секунд, так и остаётся.

А можно-ли как-то из самого мейк-файла передавать мейк-утилите эту же информацию что и аргумент j?

Попробовал подобным образом сделать ребилд, т. е.

Получил следующую хохму - в одном потоке делалась компиляция, а в другом благополучно всё чистилось. Таким образом, когда дело дошло до линкера, то вылезла масса ошибок из-за нехватки объектных файлов.

Всё. Последний аргумент перехода на scons.
там это всё вручную планируется, с нужным результатом

Из окружения (и на каждом компе своё), в переменной MAKEFLAGS
(через эту же переменную передаются флаги «вложенным» вызовам $(MAKE) )


Так если в файловом менеджере запустить копирование какого-то каталога и тут же чразу его удаление, так тоже весело будет.

Если на -j рассчитывать, то надо бы цель отдельную

У меня была именно такая цель:

И всё равно с -j получилась ерунда - при первом вызове ничего не произошло (как будто всё up-to date), и лишь при втором начало-таки компилироваться.
Но, что меня удивило больше - скорость компиляции визуально не изменилась. Поэтому я убрал -j, отложив многопоточную сборку до освоения scons (то есть до следующей жизни ).

eCos по умолчанию собирается -j 4

То что надо, спасибо!

У меня для сборки всех конфигураций понаписаны батники типа этого (в таком варианте гонки целей исключены, но хотелось бы более элегантное решение найти):
Эффект от многопоточной сборки значительный: вместо 13 минут всё за 7 минут пересобирается.
И чем больше исходников в проекте тем эффект более выражен.А что за процессор в компьютере?

Pentium dual-core 2GHz.
Сейчас замерил с секундомером, разница-таки есть: 35 сек против 40. А с -j 2 - 30 сек.

Конечно, цель-то таки ж не такая.
Тут build зависит от двух других, которые могут и в разном порядке достигаться. Если сначала достигнется all (проверили — всё на месте) и только потом clean (пока то проверялось — составляли список чего тереть), то такой эфект и будет.

Я привёл цель без зависимостей с двумя последовательными действиями, каждое из которых может распараллеливаться, но между ними «точка следования» :-)

Сейчас на ноуте с i3 (два ядра по два потока) типовая команда make -j 4 program, ещё ни разу непоняток из-за кривого порядка не было.

Да, наверняка всё так и есть. Но мне это не нравится.
Часто вижу варианты типа:

Получается, что все эти варианты тоже будут глючить от многопоточности. Имхо, надо было и в такой перечень целей вставить «точки следования».

AHTOXA
+1
Любую переделку мейкфайлов считаю моветоном.

Банальная безграмотность создателей таких make файлов.

Ой ли? Сдаётся мне, что ключ -j появился далеко не сразу. И к этому времени было уже очень много таких вот "безграмотных" мейкфайлов.