You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Handle virtual / phony make targets consistently and more robustly #104490
The reason and rationale for the change is given in the PR (gh-104491). I'm quoting it here:
By convention make targets that don't refer to a file have a dependency on the fake .PHONY target/file. This ensures that these targets are always evaluated because there is no rule to create a .PHONY file and that will force make to think the rule is out of date and needs to be rebuilt.
This commit consistently associates our virtual targets with .PHONY by declaring the .PHONY dependency immediately above the make rule.
Before, some .PHONY associations were inline (as this patch establishes). Others were defined in common blocks. Even others were defined incorrectly, actually assigning a .PHONY variable instead of operating on the make target!
Before, not all virtual targets had .PHONY associations. And there were some defined .PHONY associations in common blocks whose targets had long been deleted.
Hopefully the unified convention will prevent things from getting out of sync going forward.
Why do this?
First, consistency is good. Now people don't have to know to look for a separate block of .PHONY attribution. Hopefully this prevents missing .PHONY annotations going forward.
Second, there are some cases where virtual make targets are virtual / phony when they shouldn't be. These are creating race conditions and avoidable rebuilds across multiple make invocations. e.g. a make all
make install invocation will perform PGO+BOLT if BOLT is enabled because profile-opt and bolt-opt are phony and always invoked. I plan follow-ups to this cleanup to fix some bugs I've run into.
Feature or enhancement
I already typed a detailed commit message explaining this. Will be explained by forthcoming PR linking to this issue.
Linked PRs