VS>> (это так объясняют в VS>> https://www.cmcrossroads.com/article/rules-multiple-outputs-gnu-m VS>> ake) т.е. от лишней траты вычислительных ресурсов до возможного VS>> повреждения файлов, если в них станут писать одновременно. В VS>> реальности ведь там не touch).
EG> Так что там в реальности-то? Если это нечто пишет в файл, не создавая EG> собственных блокировок против параллельной записи другой своей копией, EG> то эта проблема вообще не имеет отношения к make и решается EG> стандартно, приписыванием lockf к вызову этого нечта.
Приписывание lockf IMHO приведёт только к тому, что вторая ветка make дождется выполнения первого экземпляра нечта и таки запустит второй экземпляр.
VS>> Вызов еще одного make изнутри Makefile мне в голову не приходил, VS>> это свежо. Hо "bar: foo" конечно быть не должно, это не отражает VS>> реальной зависимости. Если например прога, обрабатывающая source, VS>> решит что foo в этот раз пересоздавать не надо, случится VS>> что-нибудь странное.
"We can work around this by changing the generate_parser rule so that it also creates a file on disk named "generate_parser"; then on an incremental build, make will see that the file "generate_parser" is newer than parser.i and will not rebuild. But this is messy: we'll have an extra file hanging around that serves no purpose other than to work around a *deficiency* *in* *the* *build* *tool*, and we need to remember to manage that file along with the other outputs of the build. It should be deleted by "make clean", for example. And if somebody does something like "touch generate_output" in between builds, that make may not be able to correctly detect that parser.c and parser.h must be rebuilt. As with the previous solution, if you only do from-scratch full builds, this solution will work fine, but with incrementals you need to be careful."
