Fix missing include dir for untwine

[m-kuhn]

Fixes the broken windows build.
Followup #59160

CC @uclaros

[uclaros]

Does it actually fix it? FatalError.hpp is in /external/untwine/untwine/ which is already in the include dirs

[m-kuhn]

Just deducing from the error msg in #59160 (comment), tests will tell

[uclaros]

Ah, I see, the file is included using it's parent folder too!

[github-actions]

🪟 Windows builds

Download Windows builds of this PR for testing.
Debug symbols for this build are available here.
(Built from commit 0215bd0)

🪟 Windows Qt6 builds

Download Windows Qt6 builds of this PR for testing.
(Built from commit 0215bd0)

[m-kuhn]

@uclaros there are more issues (about wchar_t/unicode on windows)

Could you have a look at that?

D:\a\QGIS\QGIS\external\untwine\api\QgisUntwine_win.cpp(45): error C2664: 'BOOL CreateProcessA(LPCSTR,LPSTR,LPSECURITY_ATTRIBUTES,LPSECURITY_ATTRIBUTES,BOOL,DWORD,LPVOID,LPCSTR,LPSTARTUPINFOA,LPPROCESS_INFORMATION)': cannot convert argument 9 from 'STARTUPINFO *' to 'LPSTARTUPINFOA'
D:\a\QGIS\QGIS\external\untwine\api\QgisUntwine_win.cpp(52): note: Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or parenthesized function-style cast
C:\Program Files (x86)\Windows Kits\10\\include\10.0.22621.0\\um\processthreadsapi.h(369): note: see declaration of 'CreateProcessA'
D:\a\QGIS\QGIS\external\untwine\api\QgisUntwine_win.cpp(45): note: while trying to match the argument list '(const _Elem *, _Ty *, int, int, int, int, int, int, STARTUPINFO *, PROCESS_INFORMATION *)'
        with
        [
            _Elem=char
        ]
        and
        [
            _Ty=char
        ]

[uclaros]

It looks like I reverted a change from #58563 by pulling the latest untwine (we should have pushed that change to upstream untwine I guess).

Can you try changing again

QGIS/external/untwine/api/QgisUntwine_win.cpp

Line 31 in 8f1a6e3

STARTUPINFO startupInfo;

to

 STARTUPINFOA startupInfo; 

?

[m-kuhn]

Yes, exactly, feel free to push to this PR until it's green or start a new one and merge this.

[m-kuhn]

I think if we wouldn't vendor untwine and only keep the QGIS specific code, we'd be in a much better situation with respect to upstreaming things :-)

[m-kuhn]

Thanks looks like we are green again. Let's hope tests are working for the next version bump, so we are prepared.

[uclaros]

I'll push this change to upstream untwine so we're ok next time.
Any changes to our vendored copies should be somehow synced to their upstreams though, or we'll be dealing with such issues (I see #58563 also modified MDAL).

I think if we wouldn't vendor untwine and only keep the QGIS specific code, we'd be in a much better situation with respect to upstreaming things :-)

Unfortunately, there are no packages for untwine, nor lazperf that we could use.

[m-kuhn]

I'll push this change to upstream untwine so we're ok next time.

Thanks

#58563 you will see that it refs multiple previous iterations, with the vendored copy the path of this two-way-sync is not easy (i.e. we don't keep patches, we have a copy of the code).

Unfortunately, there are no packages for untwine, nor lazperf that we could use.

I have tried to create packages and failed because of the architecture, see #57414 (comment) . As long as the code is like this, more packaging is unlikely to happen.