On Sat, Mar 02, 2019 at 08:57:57PM +0100, Johannes Schindelin wrote: > Hi Peff, > > On Fri, 1 Mar 2019, Jeff King wrote: > > > On Fri, Mar 01, 2019 at 04:36:19PM -0500, Jeff King wrote: > > > > > > This has one notable consequence: we no longer include > > > > `command-list.h` in `LIB_H`, as it is a generated file, not a > > > > tracked one. > > > > > > We should be able to add back $(GENERATED_H) as appropriate. I see you > > > did it for the non-computed-dependencies case. Couldn't we do the same > > > for $(LOCALIZED_C) and $(CHK_HDRS)? > > > > Answering my own question somewhat: $(CHK_HDRS) explicitly ignores the > > generated headers, so we wouldn't want to bother re-adding it there > > anyway. Possibly $(LOCALIZED_C) would care, though. The generated file > > does have translatable strings in it. > > Yes, and it is defined thusly: > > LOCALIZED_C = $(C_OBJ:o=c) $(LIB_H) $(GENERATED_H) > > So it does include the generated headers explictly anyway, with or without > my patch. Oops, I should have read the source more carefully before responding. Is it worth mentioning in the commit message? I.e., something like: This has one notable consequence: we no longer include `command-list.h` in `LIB_H`, as it is a generated file, not a tracked one, but that is easily worked around. Of the three sites that use `LIB_H`, two (`LOCALIZED_C` and `CHK_HDRS`) already handle generated headers separately. In the third, the computed-dependency fallback, we can just add in a reference to $(GENERATED_H). -Peff