Re: [PATCH 1/2] mingw: avoid relative `#include`s

[Junio C Hamano <gitster@pobox.com>]

Johannes Sixt <j6t@kdbg.org> writes:

> Why is this needed?

;-)

As pointed out by Matthias, the changes in the posted patch are not
complete/comprehensive.

> With #include "foo" it is quite clear that the file is first looked up
> from the directory of the file being processed. The changed code
> requires that the top-level directory is among the -I directives of the
> command lines. Then it would be much more logical to use #include <foo>
> instead.

I actually prefer that, but that is a taste thing I do not want to
impose on this project.

> So, IMO, the status quo is perfect and does not need this change.

I tend to agree, but it would be a waste of time to further discuss
on this.  As long as it does not break compilation, I'll just let
the patch graduate.

My preference is to 

 * always name custom headers using the path from the top-level (we
   use -I in BASIC_CFLAGS exactly for this purpose), 
   e.g.

	#include "compat/win32.h" (good)
	#include "win32.h" (not good)

 * compat header that aims to replace system supplied headers like
   <regex.h> should use -I appropriately and appear as if they are
   from the system, e.g.

	#include <regex.h> (good)
	#include "compat/regex/regex.h" (not good)

If somebody truly wants to improve things once the dust settles from
these patches, I would appreciate they keep the above in mind.

THanks.