Re: [RFC PATCH 3/3] core: improve header dependencies

David Aguilar <davvid@gmail.com> writes:

Hmm, I am not sure if that is a good move, and suspect that it is incompatible with what your 2/3 attempts to do, at least at the philosophical level.

I am guessing that your 2/3 wants to see

	gcc $header.h

to be happy. One benefit from doing such a change is that sources that want to use declaration made in $header.h have to include that $header.h without having to worry about what other things the implementation detail of $header.h needs. If function F or type T is declared in header H, you include H and you are done.

That is nice and tidy, but if that is the goal, then after making H include its own dependency H1 that happen to declare functions F1, F2 and types T1, T2 (which are necessary for H to be complete as standalone), if the source that used to include both H and H1 because it uses F and F1 should still explicitly include H1, no?

For example, you dropped "diff.h" from builtin/add.c, but the implementation of builtin/add.c needs access to diff_options struct, which is in "diff.h", not whatever happened to include indirectly that is already included by builtin/add.c. I do not think it is a good idea, and more importantly I suspect that it is not consistent with what you tried to do with your 2/3.

But it is entirely possible I am misunderstanding the real motivation behind these changes. The log message justifies why removal is safe i.e. "have already been included indirectly", and the title claims it is an improvement, but there is no explanation why it is an improvement (which would have also explained the motivation behind it), so it is a bit hard for me to guess.