Re: [PATCH 1/2] mingw: avoid relative `#include`s
- From
Johannes Sixt <j6t@kdbg.org>
- Date
- Oct 12, 2025, 11:45 UTC
- Message-ID
- <e593886e-eeb4-440f-a317-a2959577e1e3@kdbg.org>
- In-Reply-To
- <484ef8b825e5d1d68a61f0f8cc2520457e8f4f3a.1759995961.git.gitgitgadget@gmail.com>
Am 09.10.25 um 09:46 schrieb Johannes Schindelin via GitGitGadget:
Show 46 quoted lines
> From: Johannes Schindelin <johannes.schindelin@gmx.de> > > We want to make them relative to the top-level directory. > > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> > --- > compat/mingw.c | 20 ++++++++++---------- > 1 file changed, 10 insertions(+), 10 deletions(-) > > diff --git a/compat/mingw.c b/compat/mingw.c > index 8538e3d172..da99473f56 100644 > --- a/compat/mingw.c > +++ b/compat/mingw.c > @@ -1,22 +1,22 @@ > #define USE_THE_REPOSITORY_VARIABLE > #define DISABLE_SIGN_COMPARE_WARNINGS > > -#include "../git-compat-util.h" > +#include "git-compat-util.h" > #include "win32.h" > #include <aclapi.h> > #include <sddl.h> > #include <conio.h> > #include <wchar.h> > -#include "../strbuf.h" > -#include "../run-command.h" > -#include "../abspath.h" > -#include "../alloc.h" > +#include "strbuf.h" > +#include "run-command.h" > +#include "abspath.h" > +#include "alloc.h" > #include "win32/lazyload.h" > -#include "../config.h" > -#include "../environment.h" > -#include "../trace2.h" > -#include "../symlinks.h" > -#include "../wrapper.h" > +#include "config.h" > +#include "environment.h" > +#include "trace2.h" > +#include "symlinks.h" > +#include "wrapper.h" > #include "dir.h" > #include "gettext.h" > #define SECURITY_WIN32
Why is this needed?
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. But that I wouldn't regard as desirable, either, because the included file isn't from a subordinate module or library.
So, IMO, the status quo is perfect and does not need this change.
-- Hannes