public inbox for goredo-devel@lists.cypherpunks.ru
Atom feed

From: Andrey Dobrovolsky <andrey.dobrovolsky.odessa@gmail•com>
To: goredo-devel@lists.cypherpunks.ru
Subject: Re: redoing unnecessary targets when a do file is modified but the output remains unchanged
Date: Wed, 5 May 2021 16:52:35 +0300	[thread overview]
Message-ID: <CAN5FJ7cy+zgjvU6o2BKE_+QDVr=RPA4Z0cE=nmWxwi7_dHG7Fg@mail.gmail.com> (raw)

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

next             reply	other threads:[~2021-05-05 13:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-05 13:52 Andrey Dobrovolsky [this message]
2021-05-05 15:11 ` redoing unnecessary targets when a do file is modified but the output remains unchanged Sergey Matveev
  -- strict thread matches above, loose matches on Subject: below --
2021-05-05 18:35 Andrey Dobrovolsky
2021-05-04 22:52 Andrey Dobrovolsky
2021-05-05  7:35 ` Sergey Matveev
2021-02-17 20:40 Karolis K
2021-02-21  8:38 ` Sergey Matveev
2021-02-27  9:09 ` Sergey Matveev