EG>>> И в третий раз спрошу, а можно всё-таки услышать ответ? EG>>> Потому как теоретически решение от него не зависит, EG>>> но практически очень даже.
VS>> В реальности есть скрипт, который пробегает лог-файл и создаёт по VS>> нему N отчётов, каждый отчёт в свой файл. Все отчёты генерятся за VS>> один проход скрипта. Потом отчёты скармливаются другим VS>> программам. В общем-то ничто не мешает переписать этот скрипт, VS>> чтобы создавать по одному отчёту за один запуск. Hо это некрасиво VS>> и медленнее примерно в N раз.
EG> Да, это было бы плохое решение. Я в своих скриптах, для которых важно EG> отсутствие двойного запуска, добавляю в самое начало:
EG> #!/bin/sh
EG> : ${TMPDIR:=/var/tmp} EG> if [ "$1" != "-locked" ]; then EG> lockf -t0 $TMPDIR/$0.lock $0 -locked "$@" EG> exit 0 EG> fi EG> shift
EG> То есть, если запущены без блокировки, попытаться захватить EG> блокировку и если получилось - работать дальше, а иначе exit 0.
Это хорошая мера предосторожности, но мы уклонились от темы сабжей.
[dd]
EG>>> Аргумент if somebody does something like "touch generate_output" EG>>> просто смешон, а если самбоди с правами за запись в obj подменит EG>>> сгенерированные файлы там и/или подставит им фейковые mtime? VS>> В целом да, аргумент достаточно надуманный, но иллюстрирует VS>> ущербность make и костыльность workaround-а.
EG> Обожемой, а что у нас не костыльное-то?
Ну что-нибудь наверное есть.
VS>> А модификатор .WAIT нельзя как-нибудь тут полезным образом VS>> использовать?
EG> Впервые слышу про него :-)
Это я уже с тоски штудировал man make и наткнулся. Но не придумал, как применить для описанной задачи.
