До сих пор не могу четко уяснить, каким образом утилиты *никсовые make/gmake и виндовая nmake обрабатывают makefile. Во всех описаниях налегают на интуитивное понимание процесса и то, что должно получиться в итоге, а мне интересны именно нюансы, но не настолько, чтобы зарываться ради этого в исходники (которых для nmake еще и не найти).

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

Это действительно так, или есть какие-то особенности? Есть ли где-нибудь явное описание процесса как для make/gmake, так и для nmake?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>До сих пор не могу четко уяснить, каким образом утилиты *никсовые make/gmake и виндовая nmake обрабатывают makefile. Во всех описаниях налегают на интуитивное понимание процесса и то, что должно получиться в итоге, а мне интересны именно нюансы, но не настолько, чтобы зарываться ради этого в исходники (которых для nmake еще и не найти).

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

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


ЕМ>Это действительно так, или есть какие-то особенности? Есть ли где-нибудь явное описание процесса как для make/gmake, так и для nmake?

Но нафуа?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>До сих пор не могу четко уяснить, каким образом утилиты *никсовые make/gmake и виндовая nmake обрабатывают makefile. Во всех описаниях налегают на интуитивное понимание процесса и то, что должно получиться в итоге, а мне интересны именно нюансы, но не настолько, чтобы зарываться ради этого в исходники (которых для nmake еще и не найти).

Есть стандарт.
Он не задаёт алгоритм, а только требования — и это естественно, нефиг стандарту задавать алгоритм.

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

Ну где-то так и есть. С соответствующими эффектами ситуации. Например, там есть такое:

> Macros in target lines shall be evaluated when the target line is read.
> Macros in makefile command lines shall be evaluated when the command is executed.

Вот тест:

t: a b c-1 c-2

c-2:
        @echo C-2 old

X=1

a:
        @echo $X

c-$X:
        @echo C-1 $X

X=2

b:
        @echo $X

c-$X:
        @echo C-2 new $X

.PHONY: t a b c-1 c-2

Получаем выдачу:

2
2
C-1 2
C-2 new 2

Как видно, первый c-$X (пока читалось при X=1) переопределил правило для c-1, а не c-2. Но при выполнении уже подставилось X=2, как в финале.

Поэтому в ряде случаев не обойтись без подчинённых Makefile, для которых уже выполнены предварительные расчёты.

ЕМ>Это действительно так, или есть какие-то особенности? Есть ли где-нибудь явное описание процесса как для make/gmake, так и для nmake?

Здравствуйте, Marty, Вы писали:

M>Ну, там вроде был где-то нюанс — можно задать значение переменной либо в момент задания, либо с раскрытием в момент использования

Это в расширениях — BSD make (все флаворы), GNU make — первое через ":=". В стандарте нету, про nmake не в курсе.
Но оно всё равно не задаёт раскрытие в таргете прямо в этот момент.

Здравствуйте, netch80, Вы писали:

M>>Ну, там вроде был где-то нюанс — можно задать значение переменной либо в момент задания, либо с раскрытием в момент использования

N>Это в расширениях — BSD make (все флаворы), GNU make — первое через ":=". В стандарте нету, про nmake не в курсе.
N>Но оно всё равно не задаёт раскрытие в таргете прямо в этот момент.


Я последний раз с make плотно ковырялся лет 20 назад, когда делал генерацию из своей билд системы в make файлы. Зачем сейчас это всё нужно — я хз. Может, если захотелось самому парсить make файлы

Здравствуйте, Marty, Вы писали:

M>Ну, там вроде был где-то нюанс — можно задать значение переменной либо в момент задания, либо с раскрытием в момент использования

Это другое. Условия подстановки переменных обычно достаточно явно описаны, в отличие от.

M>Но нафуа?

Иногда возникает потребность собирать один проект во множестве разных конфигураций, с десятками параметров. Чтобы не поддерживать соответствие разных параметров друг другу вручную, приходится делать развесистые скрипты для сборки. Ну и в какой-то момент возникает вопрос — то ли продолжать громоздить неочевидные конструкции из средств самого make, то ли уже пора добавлять "процедурный" скрипт.

Здравствуйте, Marty, Вы писали:

M>Я последний раз с make плотно ковырялся лет 20 назад, когда делал генерацию из своей билд системы в make файлы. Зачем сейчас это всё нужно — я хз.

Хм, а как Вы задаете порядок сборки проекта, исходники которого передаете кому-то другому?

Здравствуйте, Евгений Музыченко, Вы писали:

M>>Я последний раз с make плотно ковырялся лет 20 назад, когда делал генерацию из своей билд системы в make файлы. Зачем сейчас это всё нужно — я хз.

ЕМ>Хм, а как Вы задаете порядок сборки проекта, исходники которого передаете кому-то другому?

Ну, обычно это файл проекта той среды, в которой проект и разрабатывается. На крайний случай есть CMake

Здравствуйте, Marty, Вы писали:

M>Ну, обычно это файл проекта той среды, в которой проект и разрабатывается.

Если проект не имеет особого смысла в отрыве от среды, или среда настолько универсальна, что ее используют почти все — годится. Ну а если среда не сама ходовая? Я, например, до сих пор работаю в VS 2008 с SDK/WDK 6.1, у большинства покупателей давно более новые студии и SDK/WDK, причем разные версии. А когда-то у меня из одного набора исходников собирался и VXD для Win9x, и SYS для NT — этого вообще никакой средой без дополнительных костылей не сделать. Для покупателей завязка на среду (в то время — VS 6) получалась совершенно непосильной, пришлось городить набор скриптов.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>До сих пор не могу четко уяснить, каким образом утилиты *никсовые make/gmake и виндовая nmake обрабатывают makefile. Во всех описаниях налегают на интуитивное понимание процесса и то, что должно получиться в итоге, а мне интересны именно нюансы, но не настолько, чтобы зарываться ради этого в исходники (которых для nmake еще и не найти).

исходники nmake есть на гитхабе
потрудитесь прикладывать усилия
а мануалов так тем более хватает, с наглядными примерами

[skip бурные фантазии]

ЕМ>Это действительно так, или есть какие-то особенности? Есть ли где-нибудь явное описание процесса как для make/gmake, так и для nmake?

т.е. за >10 лет использование ddk где примеров разных сценариев овер, вы не осилили ?

Здравствуйте, reversecode, Вы писали:

R>потрудитесь прикладывать усилия

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

R>а мануалов так тем более хватает, с наглядными примерами

В каких мануалах явно описана последовательность проходов *make по makefile? То есть, какие конструкции всегда просматриваются/выполняются строго от начала к концу файла, а какие — в порядке обработки зависимостей?

R>т.е. за >10 лет использование ddk где примеров разных сценариев овер, вы не осилили ?

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

Здравствуйте, Евгений Музыченко, Вы писали:

M>>Ну, обычно это файл проекта той среды, в которой проект и разрабатывается.

ЕМ>Если проект не имеет особого смысла в отрыве от среды, или среда настолько универсальна, что ее используют почти все — годится. Ну а если среда не сама ходовая? Я, например, до сих пор работаю в VS 2008 с SDK/WDK 6.1,

Ну, я так-то приврал немного со сроками. Не 20, а 15 лет назад дело было Моя билд система как раз была и заточена на то, что мастер-скрипт — это солюшн и пачка проектов под MSVC2005. Из него генерились мейк-файлы для пакетной сборки под линуксы, а для возможности интерактивной отладки — генерились проекты для CodeBlocks. Теоретически (архитектурно) у меня предполагалось генерить всё из всего, но не понадобилось, а теперь есть CMake

Так и живу. Надо бы конечно уже на что-то поновее перейти.


ЕМ>у большинства покупателей давно более новые студии и SDK/WDK, причем разные версии.

Старые проекты нормально импортируются новыми студиями. Даже MSVC6 проекты, которые даже не .vcproj (а уже и не помню, какие) — нормас импортируются и собираются


ЕМ>А когда-то у меня из одного набора исходников собирался и VXD для Win9x, и SYS для NT — этого вообще никакой средой без дополнительных костылей не сделать. Для покупателей завязка на среду (в то время — VS 6) получалась совершенно непосильной, пришлось городить набор скриптов.

Ну, тут сорян. У меня тоже в моей системе было немного сложновато было кути прикрутить, но справился. Сложновато было только из-за того, что у меня всё было на моём макро-скрипт-языке, а не захардкожено. Планировал развитие

Но тут опять же — без деталей не понятно. Если всё на батниках, например, и их много — ну, можно парсер батников побыстрому запилить и генерить сборочные скрипты во что-то другое. Работы недели на две

Здравствуйте, Marty, Вы писали:

M>Старые проекты нормально импортируются новыми студиями. Даже MSVC6 проекты, которые даже не .vcproj (а уже и не помню, какие) — нормас импортируются и собираются

Только если они на кондовом C/C++, а в настройках проекта не включены дополнительные предупреждения. У меня активно используются MS Extensions, и все проекты с /Wall, так что в каждой новой студии что-нибудь, да вылезает.

Здравствуйте, Евгений Музыченко, Вы писали:

M>>Старые проекты нормально импортируются новыми студиями. Даже MSVC6 проекты, которые даже не .vcproj (а уже и не помню, какие) — нормас импортируются и собираются

ЕМ>Только если они на кондовом C/C++,

Это ты сейчас меня обидеть хотел?


ЕМ>а в настройках проекта не включены дополнительные предупреждения. У меня активно используются MS Extensions, и все проекты с /Wall, так что в каждой новой студии что-нибудь, да вылезает.

Ну, тут я тебе не доктор.

У меня правило — средства компилятора используются только если задетекчено, что их можно использовать. Иначе — либо дефолтная реализация, либо выпадаем в ошибку компиляции

Хз чем тут мейк-файлы помогут

Может проще написать свой язык/язычок для сборки своих проектов, с учетом всех западней, и генерить из него самый наитупейший мейк-файл, который будет однозначно интерпретироваться везде

Дел-то на неделю, ну, на две, максимум