EG>>> Так что там в реальности-то? Если это нечто пишет в файл, не EG>>> создавая EG> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
EG> И в третий раз спрошу, а можно всё-таки услышать ответ? EG> Потому как теоретически решение от него не зависит, EG> но практически очень даже.
В реальности есть скрипт, который пробегает лог-файл и создаёт по нему N отчётов, каждый отчёт в свой файл. Все отчёты генерятся за один проход скрипта. Потом отчёты скармливаются другим программам.
В общем-то ничто не мешает переписать этот скрипт, чтобы создавать по одному отчёту за один запуск. Но это некрасиво и медленнее примерно в N раз.
> Так что там в реальности-то? Если это нечто пишет в файл, не создавая > собственных блокировок против параллельной записи другой своей копией, > то эта проблема вообще не имеет отношения к make и решается стандартно, > приписыванием lockf к вызову этого нечта.
Ну вот я описал выше. Исходный лог-файл один, скрипт рассчитан на один проход, зачем ему заморачиватьcя с блокировками?
(Из другого твоего письма)
> А ещё лучше без цикла и поллинга: > lockf -t0 lockfile ... && [ $? != 75 ] && lockf lockfile /usr/bin/true
Вижу нечто изящное, но не понимаю что делает. Применимо к описанной выше практической задаче?
[dd]
EG>>> foo bar: fileflag EG>>> fileflag: sources EG>>> lockf /tmp/touch.${.MAKE.PID} touch foo bar && echo -n EG>>> fileflag EG>>> clean: EG>>> rm -f fileflag ... VS>> Это некая вариация на тему "Dummy targets" из VS>> https://www.cmcrossroads.com/article/rules-multiple-outputs-gnu-m VS>> ake
EG> И она работает.
VS>> "We can work around this by changing the generate_parser rule so VS>> that it also creates a file on disk named "generate_parser"; then VS>> on an incremental build, make will see that the file VS>> "generate_parser" is newer than parser.i and will not rebuild. VS>> But this is messy: we'll have an extra file hanging around that VS>> serves no purpose other than to work around a *deficiency* *in* VS>> *the* *build* *tool*, and we need to remember to manage that file VS>> along with the other outputs of the build. It should be deleted VS>> by "make clean", for example. And if somebody does something VS>> like "touch generate_output" in between builds, that make may not VS>> be able to correctly detect that parser.c and parser.h must be VS>> rebuilt. As with the previous solution, if you only do VS>> from-scratch full builds, this solution will work fine, but with VS>> incrementals you need to be careful."
EG> Я не вижу никаких практических препятствий к использованию этого EG> метода. Более того, я активно использую его на практике и не только EG> для сборки чего-нибудь.
[dd]
EG> Аргумент if somebody does something like "touch generate_output" EG> просто смешон, а если самбоди с правами за запись в obj подменит EG> сгенерированные файлы там и/или подставит им фейковые mtime?
В целом да, аргумент достаточно надуманный, но иллюстрирует ущербность make и костыльность workaround-а.
А модификатор .WAIT нельзя как-нибудь тут полезным образом использовать?
