On 08/08/2016 06:30 PM, Johannes Sixt wrote:
> Am 07.08.2016 um 22:34 schrieb Ramsay Jones:
>> [...] I would rather the 'enum iterator_selection' be defined
>> before this declaration. One solution could be to #include "iterator.h"
>> prior to _all_ #include "refs/refs-internal.h" in all compilation units
>> (Note it is in the opposite order in refs/iterator.c). Alternatively, you
>> could put the #include "../iterator.h" into refs/refs-internal.h directly
>> (some people would object to this).
>
> I concur. Which one is the correct way to do, I do not know, either.
> It's a matter how the interface is intended to be used. Perhaps the
> typedef must be moved to iterator.h?
Thanks for noticing this problem.
The enum is meant to be available for the use of any iterator-type
module, of which there are currently only ref-iterator and dir-iterator,
and the latter doesn't happen to use this enum. I'd rather not move it
to ref-internal.h because I think keeping it in a more public place will
encourage people implementing other types of iterators to reuse it.
My understanding of the project policy is that it is OK for one header
file to include another header file iff the second header file is
necessary for the correct compilation of the first (but not only because
users of the first will usually want the second as well). So my
suggestion is to add an `#include "iterator.h"` to refs-internal.h.
I also just realized that most "*.[ch]" files that live in
subdirectories use
#include "foo.h"
to include header files from the main directory, but some (including
refs/files-backend.c) use
#include "../foo.h"
I suspect that this inconsistency might cause problems for make and the
automatic dependency generation that it relies on, so the latter should
probably be changed to use the shorter pattern.
Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html