Make, ускорение процесса сборки проектов Опции

[demiurg_spb]

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

Код

make -j 4 all

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

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

[AHTOXA]

Про определённый порядок выполнения зависимостей нигде никогда ничего не гарантировалось.

Пока не появился ключик -j - вполне себе гарантировалось

Всё что вы просили выполнить в вашем makefile для цели all будет добросовестно выполнено. Вывод на экран сообщений был? Размер выводился? elf собирался? При любом ключе -j ?

Нет. В моём примере (build: clean all) - как раз-таки ничего не собиралось. Ибо сначала выполнялась цель all, а потом - clean. В результате после выполнения make build - никакого elf-а не было.

«Ага, щас»™
В результате для

Код

%.elf : $(OBJS)

между файлкми из $(OBJS) будет по точке следования и -j N идёт лесом. Параллельно их создавать будет нельзя.

Так я про PHONY цели. Между ними (после них) вполне можно было поставить точки следования.

[Petka]

Пока не появился ключик -j - вполне себе гарантировалось

После этого утверждения была бы уместна ссылка на документацию какой-то определённой версии make. С подтверждением этого смелого утверждения.

Нет. В моём примере (build: clean all) - как раз-таки ничего не собиралось. Ибо сначала выполнялась цель all, а потом - clean. В результате после выполнения make build - никакого elf-а не было.
...

В этом примере для цели build необходимо удовлетворение двух взаимоисключающих подцелей. Вы так построили сценарий для make. При чём тут инструмент?
Мне вся эта ситуация напоминает появление процессоров с "Hyper-threading". Тогда программисты не были готовы к настоящему параллельному выполнению потоков и отсутствие всяких "spin_lock" приводило к непредсказуемым результатам.

[AHTOXA]

После этого утверждения была бы уместна ссылка на документацию какой-то определённой версии make. С подтверждением этого смелого утверждения.

Это совершенно очевидно. Один поток - цели выполняются последовательно.

В этом примере для цели build необходимо удовлетворение двух взаимоисключающих подцелей. Вы так построили сценарий для make. При чём тут инструмент?

Не взаимоисключающих, а последовательных. Без -j всё работает как задумано. Если бы при добавлении ключика -j ввели точки следования после каждой из PHONY-целей, то всё бы работало и с -j. Я считаю это большой глупостью авторов make.
Короче, вы меня не переубедите. Инструмент этот (make) - кривой. Уж сколько времени я им пользуюсь, а ощущение кривизны не проходит, а только усиливается.

[ReAl]

Я считаю это большой глупостью авторов make.

Вот что-то мне в этой фразе не понравилось :-)
Это 50% пинка, вся остальная тема — ещё 50%
Всем спасибо, пинок застаивл еще раз заглянуть в документацию :-)

Код

.NOTPARALLEL: start dirs clean reset OK

:-(
Тьху, не оно :-(
Разница во времени на мелком проекте небольшая и линкеовка с LTO занимает около половины, без LTO и с time стало хорошо видно, что полностью. отрубается параллельность. Ну и не дочитался сразу, что зависимости к этой цели по барабану, главное, что она есть в Makefile.
Ну, значит, нужен feature request на .SEQUENTIAL и доброволец на реализацию :-)


Всё равно было полезно поговорить :-)
сlean я делаю отдельно вручную.
Но прошёлся по более-менее актуальным для себя Makefile, в одном старом было rebuild, в нескольких других (все в примерах scmRTOS) цель build.

Заменил на уже предложенное мной

Код

build:
    $(MAKE) clean
    $(MAKE)

В том числе во всех CortexM3/GCC примерах и вбросил изменения в репозиторий.

[mdmitry]

Код

build:
    $(MAKE) clean
    $(MAKE)

Скажите, пожалуйста, в чем смысл в цели build _всегда_ делать clean? Если меняется код только в одном файле, то компилировать надо только его, а линковать всё, но в этом случае пересобирается весь проект. Время сборки увеличивается.

[AHTOXA]

Скажите, пожалуйста, в чем смысл в цели build _всегда_ делать clean?

Потому что цель такая - полная пересборка. Для выборочной пересборки, о которой вы говорите, есть цель all.

[mdmitry]

Потому что цель такая - полная пересборка. Для выборочной пересборки, о которой вы говорите, есть цель all.

Цитата из makefile_template для Winavr

Код

# Default target.
all: begin gccversion sizebefore build sizeafter end

# Change the build target to build a HEX file or a library.
build: elf hex eep lss sym
#build: lib

Мне понятно, что цель build является частью общей цели all. На мой взгляд логично исходя из названия целей.
Скажите, пожалуйста, какие причины причины побудили Вас сделать иначе?

[ReAl]

Цитата из makefile_template для Winavr
...
Мне понятно, что цель build является частью общей цели all. На мой взгляд логично исходя из названия целей.
Скажите, пожалуйста, какие причины причины побудили Вас сделать иначе?

"иначе" -- это цель, которую можно было бы назвать rebuild («Потому что цель такая - полная пересборка.») назвать все-таки build ?
Ну, например, потому, что человек считает простой вызов make -- так, по дороге отладочным.
А вот когда нужно сделать build программы (пишут же «XXX version YYY build ZZZ» а не «rebuild ZZZ»), то тогда и вызывается make build.

Впрочем, я сам больше склоняюсь к имени rebuild :-)

Кстати, по поводу make clean all и -j. Code::Blocks по кнопке «пересобрать» сам последовательно запускает make clean и make, поэтому ничего и не вылазит :-)

Мне кажется существенным выгрышем по сборке было бы использование чего нить такого, что не заставляет пересобирать ВЕСЬ проект.

А никто тут и не пересобирает ВЕСЬ проект при каждом изменении одной буквы в листовом файле проекта. Это так, в нескольких сообщениях обсуждается название цели, которая используется для (выделенной в отдельную цель, нечастой, осознанно вызываемой) полной пересборки.