Makefile

Eugene Grosbein написал(а) к All в May 18 20:46:15 по местному времени:

14 мая 2018, понедельник, в 16:56 NOVT, Eugene Grosbein написал(а):

EG> It depends. От того, возвращает ли "нечто" когда-нибуь
EG> код ошибки EX_TEMPFAIL (75) и нет. Если нет, то проблема решается через
EG> lockf -t0 ... && [ $? != 75 ] && while [ ! -s foo ]; do sleep 1 || break; done
EG> то есть если lockf вернул EX_TEMPFAIL из-за блокировки,
EG> то это не проблема и мы просто поспим до создания foo.

А ещё лучше без цикла и поллинга:
lockf -t0 lockfile ... && [ $? != 75 ] && lockf lockfile /usr/bin/true

Eugene
--
Комбинация заискивания, подкупа и устрашения заставит молодого ученого
работать над управляемыми снарядами или атомной бомбой. (Норберт Винер)
--- slrn/1.0.2 (FreeBSD)

Victor Sudakov написал(а) к Eugene Grosbein в May 18 09:04:26 по местному времени:

Dear Eugene,

14 May 18 17:56, you wrote to me:

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...-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 нельзя как-нибудь тут полезным образом использовать?

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Eugene Grosbein написал(а) к Victor Sudakov в May 18 15:31:00 по местному времени:

16 мая 2018, среда, в 07:04 NOVT, Victor Sudakov написал(а):

EG>> И в третий раз спрошу, а можно всё-таки услышать ответ?
EG>> Потому как теоретически решение от него не зависит,
EG>> но практически очень даже.

VS> В реальности есть скрипт, который пробегает лог-файл и создаёт по нему N
VS> отчётов, каждый отчёт в свой файл. Все отчёты генерятся за один проход скрипта.
VS> Потом отчёты скармливаются другим программам.
VS> В общем-то ничто не мешает переписать этот скрипт, чтобы создавать по одному
VS> отчёту за один запуск. Но это некрасиво и медленнее примерно в N раз.

Да, это было бы плохое решение. Я в своих скриптах, для которых важно
отсутствие двойного запуска, добавляю в самое начало:

#!/bin/sh

: ${TMPDIR:=/var/tmp}
if [ "$1" != "-locked" ]; then
lockf -t0 $TMPDIR/$0.lock $0 -locked "$@"
exit 0
fi
shift

То есть, если запущены без блокировки, попытаться захватить
блокировку и если получилось - работать дальше, а иначе exit 0.

>> Так что там в реальности-то? Если это нечто пишет в файл, не создавая
>> собственных блокировок против параллельной записи другой своей копией,
>> то эта проблема вообще не имеет отношения к make и решается стандартно,
>> приписыванием lockf к вызову этого нечта.
VS> Ну вот я описал выше. Исходный лог-файл один, скрипт рассчитан на один проход,
VS> зачем ему заморачиватьcя с блокировками?

Чтобы не повредить создаваемые файлы.

VS> (Из другого твоего письма)
>> А ещё лучше без цикла и поллинга:
>> lockf -t0 lockfile ... && [ $? != 75 ] && lockf lockfile /usr/bin/true
VS> Вижу нечто изящное, но не понимаю что делает. Применимо к описанной выше
VS> практической задаче?

Рассчитано на команду, которая сама не использует lockf -
попытаться обернуть её в блокировку и если получилось, то и норм,
а если блокировка уже стоит, то подождать её отпускания без цикла.

EG>> Аргумент if somebody does something like "touch generate_output"
EG>> просто смешон, а если самбоди с правами за запись в obj подменит
EG>> сгенерированные файлы там и/или подставит им фейковые mtime?
VS> В целом да, аргумент достаточно надуманный, но иллюстрирует ущербность make и
VS> костыльность workaround-а.

Обожемой, а что у нас не костыльное-то?

VS> А модификатор .WAIT нельзя как-нибудь тут полезным образом использовать?

Впервые слышу про него :-)

Eugene
--
Enter old password: xxx
Enter new password: yyy
Confirm password: подтверждаю
--- slrn/1.0.2 (FreeBSD)

Victor Sudakov написал(а) к Eugene Grosbein в May 18 15:55:38 по местному времени:

Dear Eugene,

16 May 18 15:31, you wrote to me:

EG>>> И в третий раз спрошу, а можно всё-таки услышать ответ?
EG>>> Потому как теоретически решение от него не зависит,
EG>>> но практически очень даже.

VS>> В реальности есть скрипт, который пробегает лог-файл и создаёт по
VS>> нему N отчётов, каждый отчёт в свой файл. Все отчёты генерятся за
VS>> один проход скрипта. Потом отчёты скармливаются другим
VS>> программам. В общем-то ничто не мешает переписать этот скрипт,
VS>> чтобы создавать по одному отчёту за один запуск. Но это некрасиво
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 и наткнулся. Но не придумал, как применить для описанной задачи.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Eugene Grosbein написал(а) к Victor Sudakov в May 18 20:56:45 по местному времени:

16 мая 2018, среда, в 13:55 NOVT, Victor Sudakov написал(а):

VS> Это хорошая мера предосторожности, но мы уклонились от темы сабжей.

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

Eugene
--
Поэты - страшные люди. У них все святое.
--- slrn/1.0.2 (FreeBSD)

Victor Sudakov написал(а) к Eugene Grosbein в May 18 08:47:36 по местному времени:

Dear Eugene,

16 May 18 20:56, you wrote to me:

VS>> Это хорошая мера предосторожности, но мы уклонились от темы
VS>> сабжей.

EG> Не совсем - мы исключили повреждение файлов из-за повторного запуска.
EG> Осталась только неэффективность из-за повторного запуска,
EG> которая легко исключается файл-флагами.

Остался еще костыльный промежуточный флаг-файл для изображения зависимости цели от двух исходников. Хотя я понял твою позицию, что это костыль приемлемый.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322