building samurai on Windows using msys2 + mingw-w64

[vtorri]

hello

do you plan to support the Windows platform ?

[vtorri]

the Windows platform is not POSIX and i would like to help porting samurai to Windows. I'm currently porting muon to Windows and it would be nice to have them on Windows.

My plan would be to use native Windows API, first using MSYS2+mingw-w64, then trying with Visual Studio

but that would mean that some files are partly written for Windows. If you agree, what about having posix/ and windows/ subdirectories ?

thank you

[eli-schwartz]

In e.g. #13 and #37, Windows support was proposed and attempted, but the first was closed due to inactivity and the second due to unexpected challenges in the library which was attempted to use for Windows process handling support.

See the "proc" and "windows" branches of this repository, which have bits and pieces of logic for abstracting the operating system. I'd say that @michaelforney is definitely interested.

Note that they follow a general trend of using posix.c or foo-posix.c instead of subdirectories, so I would guess that that is the preferred approach. e.g. make OS=windows and for OS-specific files you would build with foo-$(OS).c. It's not meaningfully different from the subdirectory approach.

[vtorri]

If I begin the Windows port, I will certainly write several "small" patches, one after the other like muon. But I will begin it after muon correctly supports Windows.

[wdlkmpx]

Hmm it doesn't really make much sense since ninja is C++, the C with classes and all sorts of obscure stuff. The Windows people usually only use C++, C is more often used in POSIX systems, for many CLI apps at least, so ninja has lots of support from the Windows crowd (I think)

The ninja project even releases windows binaries, but only x86_64 binaries, people forget that x86 is still in use
https://github.com/ninja-build/ninja/releases/tag/v1.11.1

So, you should focus on testing and merging the current open PRs so that samurai doesn't lag behind ninja in the battle of swords.

See it as lzip, which is a C++ app, there's also clzip which is the C implementation to maximize portability with IoT devices and stuff

It makes sense for POSIX systems because that's a huge family with all sorts of use cases, people build their own linux "distros" and so on, ninja is not that big statically linked either (including libstdc++)

[vtorri]

@michaelforney as the development of muon is stalled these days, i decided to look at the windows port of samurai. the work is based on what you done in the windows branch and git.

do you prefer to have big PRs, or small PRs ?

some remarks:

• Windows has no UTF-8 support either ansi or UTF-16 (using wchar_t) for file names. ansi can be used for UTF-8, but for some languages, it will not work. Do I keep the usage of char ? Other options : see https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file and https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry
• if I keep ansi, the maximum path length will be 260. It will be 32768 for UTF-16
• PATH_MAX is used but is not defined with Visual Studio (i test with both mingw64 and VS). As it is a macro, i think that I will need to use a #ifdef _WIN32 in a source code. Is it annoying ?
• I think that all the fopen() should use the binary translation mode (and log message should mention fopen and not open)

[vtorri]

@michaelforney i can also add a prefix for the functions in os.h, like os_mkdir. Or samu_mkdir.

[vtorri]

@michaelforney here is my first attempt for windows port:

103e01c

i did something wrong with the last commit it seems (2 commits were merged), but code is there

it remains build.c which is a bit tricky

feel free to send remarks

thank you