Two things / FAQ related

[Dru Nelson]

Hi,

1. I want to see if I understand this correctly.

Lets say you made an 'all.do' that consisted entirely of redo-ifchange lines.

If you did 'redo', and nothing was changed, then nothing should be rebuilt.

Correct?

2. You mention that redo will do a build if a file is touched. This is interesting. Does this imply that basically the specific project's redo scripts are not tracking a dependency. (For example, maybe the compiler changed?)

Dru

[Dru Nelson]

Any thoughts on this?

[Nils Dagsson Moskopp]

Dru Nelson <dru...@gmail.com> writes:

> Hi,
>
> 1. I want to see if I understand this correctly.
> Lets say you made an 'all.do' that consisted entirely of redo-ifchange
> lines.
> If you did 'redo', and nothing was changed, then nothing should be rebuilt.
> Correct?

Not necessarily: With redo-always, for example, you can add a dependency
that is always out of date. Some redo implementations also

> 2. You mention that redo will do a build if a file is touched. This is
> interesting. Does this imply that basically the specific project's redo
> scripts are not tracking a dependency. (For example, maybe the compiler
> changed?)

Caution, not all redo versions do a build if a file is touched. My own
redo implementation, for example, will hash files if the filesystem is
indicating that the file has been modified (GNU coreutils: stat -c%Y).
If a file changed, it does mark it as not up to date and may rebuild …

Avery Pennarun's redo implementation may refuse to overwrite that file
with a different hash, outputting “you modified it, skipping”. We seem
to disagree regarding that issue – I think if redo exits with a status
indicating success should indicate that my targets are now up to date.

[Dru Nelson]

Hi Nils,

Thanks for your reply.

So, for the first question. Can I infer that I am correct. If an 'all.do' contains nothing but 'redo-ifchange' commands, then the system will not build under a standard run of the command 'redo'.

BTW, that makes me wonder. How does redo-ifchange know what 'do' script it is being run from?

In DJB's document, he states:

https://cr.yp.to/redo/honest-script.html

For example, dhcpd.do can say
     redo-ifchange cc dhcpd.deps
     redo-ifchange `cat dhcpd.deps`
     ./cc -o dhcpd `cat dhcpd.deps`
to indicate that dhcpd depends on cc, dhcpd.deps, and the files listed in dhcpd.deps. You don't have to say redo-ifchange dhcpd.do; that's assumed.

I guess it must record that on the first pass, when building the database. Maybe via an environment variable. Otherwise, if you run it from the command line, how would it know what 'do' script it was run from.

With regards to the second question, I'm asking a higher level question. Why would such a feature be needed if all the dependencies were tracked? 

Hopefully Avery will see this email and chime in.

Cheers,

Dru

[Tim Allen]

On Tue, Aug 13, 2019 at 01:39:19AM -0500, Dru Nelson wrote:
> 2. You mention that redo will do a build if a file is touched. This is
> interesting. Does this imply that basically the specific project's redo
> scripts are not tracking a dependency. (For example, maybe the compiler
> changed?)

I don't really understand this question.

If a particular project's documentation mentions "after changing X,
touch file Y to make the build work", then yes, that sounds like a bug
in the build-scripts for that project. However, there's other reasons
why redo wants to support "touch a file to trigger parts of the build
process":

- The alternative to checking mtimes is to check the file contents,
for example by hashing. This vastly more expensive than just
checking the mtime.

- Other, more widely-used build systems (like make) have this
behaviour, and the Principle of Least Surprise says redo should
have it too, unless it actually causes problems.

[Nils Dagsson Moskopp]

Tim Allen <scre...@froup.com> writes:

> On Tue, Aug 13, 2019 at 01:39:19AM -0500, Dru Nelson wrote:
>> 2. You mention that redo will do a build if a file is touched. This is
>> interesting. Does this imply that basically the specific project's redo
>> scripts are not tracking a dependency. (For example, maybe the compiler
>> changed?)
>
> I don't really understand this question.
>
> If a particular project's documentation mentions "after changing X,
> touch file Y to make the build work", then yes, that sounds like a bug
> in the build-scripts for that project. However, there's other reasons
> why redo wants to support "touch a file to trigger parts of the build
> process":
>
> - The alternative to checking mtimes is to check the file contents,
> for example by hashing. This vastly more expensive than just
> checking the mtime.

A redo implementation does not need to check the hash if the time
matches the last time recorded. My redo only hashes if the ctimes
indicate that a file could possibly have been changed.

By the way, one needs to check ctime, not mtime; mtime is changed
whenever file content is modified – but not updated if the owner,
group, hard link count or mode change (inode information) change.

(I guess this means that I should review some dependency checks.)

> - Other, more widely-used build systems (like make) have this
> behaviour, and the Principle of Least Surprise says redo should
> have it too, unless it actually causes problems.

I wrote my own redo implementation for a podcast build system – a
rebuild of a file that was not needed was very expensive, as that
involved encoding the file, possibly in 3 separate audio formats.

Besides, make does not rebuild targets if the build rules change,
could not track any non-existence dependencies – even if patched.

[Nils Dagsson Moskopp]

Dru Nelson <dru...@gmail.com> writes:

> Hi Nils,
>
> Thanks for your reply.
>
> So, for the first question. Can I infer that I am correct. If an 'all.do'
> contains nothing but 'redo-ifchange' commands, then the system will not
> build under a standard run of the command 'redo'.

I believe either you or me misunderstood something here. Please show
example dofiles and document exact behaviour you expect in the case.

> BTW, that makes me wonder. How does redo-ifchange know what 'do' script it
> is being run from?
> In DJB's document, he states:
>
> https://cr.yp.to/redo/honest-script.html
>
> For example, dhcpd.do can say
>> redo-ifchange cc dhcpd.deps
>> redo-ifchange `cat dhcpd.deps`
>> ./cc -o dhcpd `cat dhcpd.deps`
>> to indicate that dhcpd depends on cc, dhcpd.deps, and the files listed in

>> dhcpd.deps. *You don't have to say redo-ifchange dhcpd.do; that's
>> assumed.*

>
>
> I guess it must record that on the first pass, when building the database.

I have no idea what you mean with “first pass” – maybe first build?

> Maybe via an environment variable. Otherwise, if you run it from the
> command line, how would it know what 'do' script it was run from.

it is known before invocation which file builds a target. Check out
redo-whichdo to see how it is determined & read more documentation.

Take care – if you build dofiles during the build, information from
redo-whichdo might not match what happens, since the dofiles can be
non-existent before the build.

> With regards to the second question, I'm asking a higher level question.
> Why would such a feature be needed if all the dependencies were tracked?
> Hopefully Avery will see this email and chime in.

My opinion is that the “touch” feature is not useful at all. If you want
to force the rebuild of a target, you can either truncate it or invoke a
“redo” command with that target as an argument – then it will be redone.

Consequently, my redo implementation never rebuilds on “just touching” …

> --
> You received this message because you are subscribed to the Google Groups "redo" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to redo-list+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/redo-list/CALqrBYoM4hW3Sec_a0kiHuf%3Dbe-6CAjmxGAgs8_K7fhFxFa43A%40mail.gmail.com.