Investigate fully-native Windows builds (with Visual Studio compilers and tools)

[jimklimov]

No idea if this is (easily) possible, for NUT and/or its prerequisites, and such lack of knowledge is not good :)

[Anutrix]

Now that #1611 is merged, what's the status on this?

Note that I'm a new user/dev trying to build master branch natively on Windows(maybe using something like https://github.com/mstorsjo/llvm-mingw).
Alternatively, I'm also trying to cross-compile for Windows using WSL2.

[jimklimov]

Better read up in comments to #5 and #1611 and #1050 to an extent. The short of it is that syntactically NUT builds pass without warnings, and survive integration tests (upsd and some dummy-ups setups).

Doable in linux+mingw (using an older build script to arrange configure options) and in Windows+MSYS2 with plain configure or same ci_build.sh as CI builds on other platforms use to arrange it. Prerequisites are listed in scripts/Windows/README and docs/config-prereqs.txt respectively (or now also actionably wrapped by appveyor.yml). Known caveats are in NUT for Windows project.

[jimklimov]

In particular, "purely native" builds (e.g. with Visual Studio) were not attempted yet, not that I know of. The goal was to have something usable first, so first winners were even two - GCC builds with mingw (on linux and in MSYS2), with ccache recommended for faster iterations, with x86_64 and i686 targets. Probably clang is doable, but was not tried yet. Passing in custom CFLAGS into MSYS2 builds (as pre-set envvars or configure argument) caused issues for that build of gcc itself (somehow became part of path it is trying to build in).

Due to availability/easy-buildability of third-party dependencies, these build scenarios currently have some non-overlapping results (notably libgd/cgi, snmp and neon/xml are known inconsistencies).

USB HID may need more work, possibly installing a low-level driver in OS, to see devices in detail.

Parts of serial driver codebases are ifdef-ed away.

[jimklimov]

Note, in context of this issue, "native" compilation regarded investigation of possibility for use of platform-provided MS tools (not GNU/POSIX "semi-native" shims which luckily do work and run directly on Windows, but are not "native" platform tools).

It may quite be that things would "just work" if someone conjures up a recipe in Visual Studio, or that it does not, or is too hard because third-party deps that NUT needs are not easily available on native Windows, etc. Maybe DLLs and headers from MSYS2 or MinGW for Linux builds would just suffice as the build environment for VS, maybe not. Just got no info, nor idea, nor tools and time and inclination to try. But I can imagine that someone might want to experiment, so tracked the idea.

What you meant with LLVM would rather fall under another issue, which I meant to post but apparently forgot - so thanks, did it now at #1647

Your other idea, builds in WSL2, is functional and is quicker (Linux process spawning is cheaper, so configure script passes a lot faster), but is arguably not a native build environment, just a Linux VM hosted in Windows and integrated for /mnt/c/... filesystem access :) Docs for linux+mingw cross-builds in Ubuntu/Debian-like systems do fit that case well (including details on a dozen or two of prerequisite component builds that are not packaged by Ubuntu for mingw), and you can use the same VM for native Linux builds if you set up the docs/config-prereqs.txt tools and prerequisite packages for that (much of that overlaps anyway). In a way it is also better since it is not done in Windows native filesystem, so the antivirus does not get into your way - which is annoying in MSYS2 builds (notably BitDefender dislikes that configure script keeps rewriting conftest.exe and tends to refuse access to the file after some iterations, until you reboot; out-of-tree builds in scratch directories help work around it).

[jimklimov]

I'd suggest you do go through existing known-working ways to build NUT, whether for Linux (WSL) or Windows (cross linux+minge or MSYS2), at least to learn your way around docs and scripts involved, and have a benchmark setup to compare the improvement efforts to.

To me, once we got builds per se working with at least some toolkit (even two, on Windows and cross), adding more toolkits became a rather academic interest. Each new point of view (toolkit and technique) does expose more bugs usually, so it is always welcome.

But completing parts of NUT that are glaringly missing (commented-away parts of code here and there, the Windows installer - of kernel driver in particular - that may be related to poor usb support... or finding how to get libusb1 to just work) has IMHO higher practical priority than adding yet another compiler where it would be possible to also build the same feature-incomplete codebase, or replacing the config/build system used. Then again, if that would help you pursue practical fixes (e.g. debug via Visual Studio in a way you can't from NetBeans or some such), maybe that is a useful investment of time. I'd just be wary of spending a year for no visible gain, getting bored and fizzling out :)