I'm not sure if it's a great solution, but I suppose it'd be possible to have settings pointing to strgen and settingsgen executables to use instead of those built.

https://stackoverflow.com/a/61385572 seems to be a good option.

I tried something using the link in my previous comment in master...glx22:cross_compile

I tried something using the link in my previous comment in master...glx22:cross_compile

This fixes the issue for me, many thanks :)

Hm, I assume this works for gcc or similar, but doesn't appear to work when trying to cross-compile ARM64 on x64 with MSVC 2019. I'll have a dig around and see if I can work out a solution.

Yeah, for now I hardcoded host compiler, but I think it can be configurable.
@orudge maybe try without https://github.com/glx22/OpenTTD/blob/fdaf0d0b2f82701c8ea1e9a1125415351cf49e57/CMakeLists.txt#L143 I added these when testing mingw target on my debian VM, because it kept using mingw compiler even for the native part.

Ok I tried ARM64 on x64 with VS2019, it's not detected as cross-compiling (CMAKE_CROSSCOMPILING is false)

It's not particularly elegant, but master...orudge:msvc-crosscompile works for me when crosscompiling for ARM64 on x64. Compiling x64 and x86 on x64 work too in the conventional manner, and building with mingw-w64/msys2 also looks OK.

Alternate option in master...glx22:cross_compile_alt.
It requires more manual steps (and 2 build directories):

• create a directory for native
• run cmake for native
• build at least tools target
• create a directory for cross-compile
• run cmake for cross-compile, passing the full path to native directory in HOST_BINARY_DIR
• build cross-compile

I like your solution @glx22, and it works very well. Did you already make a PR out of this?

There is one change in your commit I am not sure is correct, the one where you add a WIN32 line .. feels a bit out-of-place.

To make it an official option in CMake, might be good to set HOST_BINARY_DIR somewhere, with a description? So people who use the CMake GUI know about it too :)