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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 13, 2025, 16:29 UTC
Message-ID: <xmqqa51u3guw.fsf@gitster.g>
In-Reply-To: <e593886e-eeb4-440f-a317-a2959577e1e3@kdbg.org>

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.

Show 5 quoted lines

> 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.