Re: redoing unnecessary targets when a do file is modified but the output remains unchanged

From: Andrey Dobrovolsky <andrey.dobrovolsky.odessa_at_domain.hidden>
Date: Wed, 5 May 2021 16:52:35 +0300
Message-ID: <CAN5FJ7cy+zgjvU6o2BKE_+QDVr=RPA4Z0cE=nmWxwi7_dHG7Fg_at_domain.hidden>
Hello!

Thanks for paying attention to my message. I'm sorry that probably it
was formulated in a wrong way, and the main meaning was not expressed
sufficiently clear. I was not pointing at my implementation as at the
reference one, I meant that dependencies processing logic, that I
used, allows to avoid unnecessary .do operations. Exactly in
correspondence with the message subject. Let me, please, take one more
attempt.

So, according to
http://lists.cypherpunks.ru/archive/goredo-devel/2102/0015.html:
>redo just:
>    determines that A is OOD, because B is OOD, and then
>    executes A.do,

In my opinion this is the origin of the problem, named in the message subject.
In my implementation if A depends on B and B is outdated, then B.do is
executed, then B is checked with the hash, and if it is found to be
changed, only after this A.do is executed.
Technically program flow may be described schematically as:

redo_target(SomeTarget)
{
    if(SomeTarget has no .do file)
        return ok;
    while(TheDep = read(DepOfSomeTarget)) {
        if(redo_target(TheDep) is not ok)
            break;
        if(CompareHash(TheDep, HashFromDepOfSomeTarget) != ok)
            break;
    }
    if(not all deps of SomeTarget are ok)
        execute(SomeTarget.do);
}

In other words if A depends on B, one can make the decision on A being
OOD only after B will be updated.

This is the main difference of my version from the original Leah
Neukirchen's, other differences are consequences and some are
implementation details, which are not important and in no way are
promoted. As I can understand, Your implementation follows the same
logic.

 You can easily compile and check my redo version on the dep trees,
that seem to be problematic, "redo" is not equivalent to
"redo-always", this was wrong impression. The only confusing may be
that alone "redo" will not build "all" target, targets must be named
directly.

I really expect the issue, pointed in the message subject, very
harmful and suppose that it can have negative influence on the redo
system wide use.

Best regards!
Andrey Dobrovolsky
Received on 2021-05-05 13:52:35 UTC

This archive was generated by hypermail 2.4.0 : 2021-05-05 14:00:08 UTC