On Tue, May 30, 2023 at 10:42 PM Daniel Ruoso <daniel_at_[hidden]> wrote:

> Em ter., 30 de mai. de 2023 às 16:05, Mathias Stearn <
> redbeard0531+isocpp_at_[hidden]> escreveu:
>
>> So I did a bit of digging and I now think it is possible to get
>> restat-like behavior out of make. The "trick" is to use a separate
>> recursive make invocation for scanning vs building.
>>
>
> I am now confused about another bit. And I'm not sure how that works for
> ninja either.
>

In ninja, it remembers when the timestamp was up to date across runs. I
believe it keeps this in the same data structure/file that it remembers the
actual command executed so that it knows to re-run on command changes, even
if all inputs are up to date.


>
> If the output of the dependency scan maintains the same timestamp, won't
> the next run think the dependency file is still out of date to its inputs
> and cause yet another run of the dependency scan?
>
> I guess we could have the scan rule have a "side-effect" that keeps the
> state as of the last time it actually changed, but the actual target is
> output to a file that represents the last run. But that means the
> dependency chain is broken and the system doesn't quite know where that
> "side-effect" comes from.
>

Something like this:

foo.cpp.scan: foo.cpp OTHER_INPUTS
  do_scan foo.cpp | post_process | write_if_different foo.cpp.scanresults
  touch foo.cpp.scan
scan_all: foo.cpp.scan

foo.cpp.o: foo.cpp foo.cpp.scanresults # this also needs to add BMIs to the
deps here somehow
  derive_flags_from_scan foo.cpp.scanresults > foo.cpp.flags
  g++ -o foo.cpp.o -c foo.cpp foo.cpp.flags
build_all: foo.cpp.o




>
> daniel
>