“inputs” is a hammer, but it results in unnecessary recompilation when the input is only relevant to the link step. Bug 796187 expands on the last paragraph of the initial bug report here, and requests a more targeted solution to this problem.

What happens if instead of a config that multiple targets use, you make them list a common target in deps?

That target can be:

group("foo") {
  public_configs = [ ":foo_config" ]
  public_deps = [ ":action_that_creates_plist" ]
}
config("foo_config") {
  visibility = [ ":foo" ]
  ldflags = [ "-sectcreate __TEXT __info_plist $plist" ]
}

I think you might get a ninja dep from anything with deps=["foo"] to a stamp file for the action running, which is a proxy for the plist file changing.
But I'm not really sure.
There might be some slightly different trick along these lines that would have the desired effect.

The current rule for configs is that it's for things non-file and -target related and it doesn't participate in the dependency graph. Generally people ask for "deps" in a config which creates significant problems that "inputs" doesn't have.

I would try starting with Roland's solution to see if you can make something work. There is a conceptual simplicity in terms of having configs be for flags only.

It certainly seems like an awkward hack to have to indirect my static in-tree plist through what amounts to a copy action just to make this work. I think I prefer bug 796187 comment 3.

Regardless, bug 796183 is a little frustrating: whether I achieve what needs to be done via a config or a dep exposing a public_config, ldflags can only be propagated out to a single dependent target, and not all the way to dependent targets that produce linker output.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I don't think we should do this. Configs are for flags and such, while "inputs" seems more like part of the dependency tree. We don't allow sources for the same reason.

The use case is flags that need an auxiliary input file, such as a linker script or other parameter file.  For such cases configs is the sensible mechanism to use, and inputs in a config is the only way to represent the necessary ninja file dependencies.

If “inputs” is a no-go, bug 796187 frames the problem in a more general way. Inputs may be the wrong tool for the job (which I concede in comment 2), but it’s not accurate to say that “configs are for flags and such”, when some tools (such as linkers) accept configuration not via flags but via files (which they may be directed to via flags). If this is indeed a WontFix, please weigh in on bug 796187 with an acceptable framework to help this move forward.