Это не причина НЕ исправлять такие makefile.
Раньше и в компиляторах не было volatile. Но это не причина НЕ исправлять старый код.

size сам зависит от elf, так что там без проблем, message_begin иногда выскакивает после compiling от первого %.o. Это немного неприятно, не не смертельно. Там и предупреждения/ошибки компилятора идут вперемешку с compiling по мере появления, всё равно смотреть потом внимательно надо :-)
И править это руки не доходят. А важные вещи, в отличие от декора, вроде как нормально (ну кроме make clean all).

По правке — полностью согласен в мнением по volatile :-)
Более того, volatile уже давно как был, но с ростом пронырливости компилятора приходится править то, где эти volatile есть, но в других местах (например, так было с чтением системного тика в scmRTOS).

Хорошо хоть, что с этих мейкфайлов снято обвинение в «безграмотности», теперь они просто «старый код»
А теперь представьте, что в следующей версии make введут новый ключик, и вам придётся править все свои мейкфайлы. Имхо, это неправильно. И сравнение с volatile здесь не совсем уместно - в случае make ничто не мешало авторам поставить между субцелями пресловутые «точки следования».

Неправильно будет, если ключик по умолчанию будет включен.
А так: не хош -- не пользуй, хош -- подстройся. Всё честно.

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

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

ИМХО вывод сообщений неправильно организовывать как подцели какой-либо цели.
По замыслу make, подцели необязательно вообще будут выполняться by design.
Про определённый порядок выполнения зависимостей нигде никогда ничего не гарантировалось.
Всё что вы просили выполнить в вашем makefile для цели all будет добросовестно выполнено. Вывод на экран сообщений был? Размер выводился? elf собирался? При любом ключе -j ?
Проводя аналогии с компиляторами: сейчас уже никого не удивляет, что в ассемблерном листинге оптимизирующего компилятора фактический порядок "промежуточных" арифметических вычислений может отличатся от написанного в исходном тексте программы. Не говоря уже о выкидывании незадействованного кода. Если программист заложился на какие-то побочные свойства инструмента - это только ответственность программиста а не проблема инструмента.

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

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

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

Это не одно и то же.
Вы указали две разные цели (clean и all). Каждая из этих целей имеет свой рецепт, и при указании -j эти два рецепта выполняются параллельно.
В примере же ReAl один рецепт из двух строк. Эти строки всегда будут выполняться последовательно независимо от наличия или отсутствия -j.

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

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

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

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

Очевидно? А почему не в обратном порядке? А почему не в алфавитном порядке? А почему не в порядке расположения файлов в файловой системе?

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

Жаль.

Тут сделал пару тестов:










Если нам важен порядок немного патчим кривой makefile без создания промежуточных целей:






Вуаля!
Может кому-нибудь будет полезно.

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


Если после каждой цели (каждого рецепта) ввести точку последовательности, то и сборка будет выполняться строго последовательно. Таким образом, весь эффект опции -j (которая как раз предписывает выполнять рецепты параллельно) будет уничтожен. В таком случае, просто не указывайте -j, и Вы получите желаемое!

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

Ну мы вроде как друг-друга поняли По факту порядок обработки целей совпадает с порядком их объявления. Хотя я и не встречал в документации явных гарантий этого.
Я написал не "каждой цели", а "каждой PHONY-цели". Так что эффект останется.

Так и делаю, не переписывать же многие десятки makefile-ов.
(И, вдохновлённый этим обсуждением, снова почитываю про scons... )

Ключик -j очень старый, лет 10 назад он уже был старым.

PS. 1989г, make, ключ -j уже имеется.

Сообщение отредактировал e-serg - Aug 28 2012, 04:00

И? Это вы к чему?

к этой фразе

более 20 лет, этот ключик "-j", у gnu make существует, новым его не назвать.