graph: always use the on-disk mtime of generator rules

[mathstuf]

Generator rules are likely to have been run outside of ninja, so the
build log should not be trusted for detecting whether or not to rerun
the rule.

---

Observed with CMake projects which exhibit behavior that ninja reruns cmake right after running cmake manually. Maybe it is better to just not add generator rules to the build log at all? I don't know of the implications of that.

See https://gitlab.kitware.com/cmake/cmake/issues/15830 for some context.

[fkaelberer]

So this should fix #1376, I guess.

[mathstuf]

Yes, it should. I suspect there are likely other duplicates of the issue around.

[Siron777]

I have tested the patch and I do not observe anymore the issue #1376.

[rubenvb]

This seems to fix issue #1376 for me.

[jhuels]

This fixes the issue for generator rule for me, but I don't think CMake provides a way to mark custom commands as generator. I'm having an identical issue with a code generator where the disc time of the output is newer because it was run outside of ninja, but ninja_log is stale.

Do you know of a way around this, or should I request a feature for CMake to set custom commands as generator?

[mathstuf]

Please open an issue over there (rather than muddying the discussion here), but include your example custom command. Ninja's rules on the generator rule variable doesn't really make sense with custom commands.

[jhasse]

Do you know of a way around this

Update the ninja_log in your custom command.

[mathstuf]

Update the ninja_log in your custom command.

I don't know that this is going to be easy. Ninja itself uses the tmpfile-and-rename style, so any command doing this would need to coordinate with ninja on what's going on. This just sounds 100% flaky to me.

[jhasse]

Ninja itself uses the tmpfile-and-rename style, so any command doing this would need to coordinate with ninja on what's going on.

But this shouldn't matter because we're talking about the case where the generator is run outside of ninja, right?

[mathstuf]

How is the tool supposed to know if it is inside or outside ninja? Plus, the question asked was for a way to claim generator = 1 in order to access the behavior introduced here. Maybe some other flag should be added that generator = 1 should imply?

[jhasse]

How is the tool supposed to know if it is inside or outside ninja?

Pass itself a flag in its build rule for example.

[mathstuf]

Maybe if the deplog format were documented and guaranteed to be stable, that route could be taken. Until then, is this a sufficient solution to the problem being seen?

[jhasse]

I would rather add a tool to Ninja (e.g. ninja -t updatecache?) or add the functionality to an existing one. What about ninja -t recompact? Or the new cleandead tool? Running the latter on reconfigures is a good idea anyway, as it might catch bugs by deleting files hanging around from previous builds.

[mathstuf]

Hmm. That could work. A pipeline like ninja -t cleandead && ninja -t recompact && ninja -t restat maybe?

[jhasse]

Exactly! restat also sounds like a good name.

[mathstuf]

Strawman MR filed for CMake here: https://gitlab.kitware.com/cmake/cmake/merge_requests/3316

[jhasse]

Closing in favor of #1685.