Исходные файлы в redo

http://lists.stargrave.org/archive/goredo-devel/4846b4ed2ecef310e4be49093d72654b@spacefrogg.net/
http://cr.yp.to/redo/atomic.html
Два раза за полгода я менял поведение определения является ли цель
исходным файлом (source file) или нет.

В goredo 2.7.0 исходным файлом является любая цель, для которой найден
.do файл. Соответственно, default.do означает, что всё в иерархии рядом
с ним и ниже будет автоматически генерироваться. Ведь логично же?

Но тогда это означает, что и любой default.*.do тоже должен быть
сгенерирован default.do, что лишает смысла их (разумного, удобного)
использования. Поэтому для default.*.do файлов я делал исключение и не
считал их генерируемыми целями, а только исходными файлами. То есть,
особое отношение к ним. Как отличить "честный" default.*.do от
генерируемого? А никак. Предполагается, что в проекте будут
соответствующие "clean" скрипты, которые оставляют требуемое
состояние .do файлов проекта.

Один из давних участников goredo рассылки привёл хороший аргумент против
такого поведения. redo это stateful система сборки. Факт. И он считает,
что исходный файл это тот, для которого нет заранее известного состояния
и он присутствует на ФС. Если удалить state, то да, ничего не будет
пересобираться, ибо оно становится исходным файлом по определению.
Каждый проект всё равно должен иметь соответствующий "clean", мол,
такова жизнь.

Я хотел было возразить: ведь .do файлы тоже являются состоянием и факт
появление того или иного .do это уже изменение достаточное для
пересборки каких-то целей. Однако, я же ведь уже сам делаю исключение в
поведении default.*.do файлов! И я же точно так же подразумеваю иметь
соответствующий "clean" для удаления default.*.do которые должны быть
сгенерированы.

Таким образом, не логично иметь подобное поведение только для
default.*.do файлов. Что мешает это делать для всех? Это меня убедило.
Что-то считается исходным файлом, хотя должно быть генерируемой целью?
Явно сообщи это state-у, путём удаления файла и запуском (пере)сборки.

DJB вообще-то даже намекает на такое определение исходного файла:

    When redo is asked to create a file that it hasn't heard of before,
    it presumes that the file is a source file if it exists, or a target
    file otherwise. In the second case (new target), redo immediately
    saves this decision to disk, so that its subsequent creation of the
    target doesn't change the decision.