*** Andrew Chambers [2022-04-14 23:30]:
>One way would be for
>goredo to store the dependency information in the directory containing the
>do file instead of the directory containing the target.

That heavily complicates everything. If you have dependency information
stored near the target itself, then finding it is trivial:

    for foo/bar/baz/TGT
    dependency information is in foo/bar/baz/.redo/TGT.rec

But if you store it "near" the .do file, then:

    for foo/bar/baz/TGT
    .do file is: foo/default.do,
    so depinfo is in: foo/.redo/bar_baz_TGT.rec (for example)

and for finding it, you have to traverse from foo/bar/baz/ directory to
uppper levels finding that bar_baz_TGT.rec file.

And you can not just call find_do_file(foo/bar/baz/TGT) and go to that
directory, because another .do file can appear after that.

    foo/bar/default.do appeared
    and it should be the default one for foo/bar/baz/TGT
    but still only foo/.redo/bar_baz_TGT.rec has dependency information

And when you rerun your target, foo/bar/.redo/baz_TGT.rec will appear...
but what to do with the left foo/.redo/bar_baz_TGT.rec? Search for
possible obsolete dependency information and delete it? It will be
impossible to do that atomically: you can not rename temporary file to
foo/bar/.redo/baz_TGT.rec and delete foo/.redo/bar_baz_TGT.rec at once.

That leads to the desire of some centralized storage, as apenwarr/redo
did. But its author decided that it was a bad idea:
https://redo.readthedocs.io/en/latest/FAQImpl/#how-does-redo-store-dependencies

Well, spacefrogg@ actually wrote about exactly all of that too.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF