[Nut-upsuser] NUT on Windows revival

[Jim Klimov]

Windoze in da NUT house!

Codebase of the NUT for Windows branch was merged to main codebase, not in
the least to avoid bit-rot and need for resynchronisation with merge
conflicts that regularly arose as the two branches "just co-existed". More
community work is needed to complete some drivers' functionality and MSI
package delivery, but for many use-cases it may already "just work" using
tarballs from AppVeyor CI.

Happy back-to-school weekend,
Jim

On Mon, Aug 22, 2022, 01:55 Jim Klimov <jimklimov+nut at gmail.com> wrote:

> "Good news, everyone!"
>
> With CI builds of the branch now regularly passing on both the
> multiplatform FOSS NUT CI farm (including linux+mingw cross-builds), and
> CircleCI with MacOS, and newly on AppVeyor with Windows+MSYS2 (including
> integration tests with live upsd and some dummy-ups instances), after
> ironing a few wrinkles I intend to PR and merge it into the main NUT
> codebase soon, lest the effort bit-rot again.
>
> There are nearly no remaining "functional" changes to lines of existing
> "POSIX" NUT codebase, with platform specifics fenced by ifdef. (There is
> quite a bit of noise with macro'ed data types that resolve same as they did
> for POSIX builds).
>
> So far it is not prime-time ready to package: some functionality remains
> ifdef-ed away, though it might have been in 2.6.5 based releases too, and I
> did not even investigate MSI generation. Also there were good ideas how to
> architect and move it forward posted over the years... But at least it
> seems already functional in many aspects and I still hope someone takes
> that torch to the finish line. Many tickets for such details posted at
> https://github.com/orgs/networkupstools/projects/2/views/1
>
> FWIW, AppVeyor builds also publish a tarball of the Win x64 install area
> to grab and test. Making sure it actually runs and talks correctly to the
> hardware is important after all ;)
>
> Jim
>
> On Wed, Jul 13, 2022, 20:06 Jim Klimov <jimklimov+nut at gmail.com> wrote:
>
>> Back from vacations, and before I dive into real-life work, I went over
>> some ideas and notes from the NUT for Windows effort.
>>
>> Now they should be tracked at
>> https://github.com/orgs/networkupstools/projects/2/views/1 and community
>> help is welcome :)
>>
>> I probably forgot or missed some caveats - so feel free to post issues
>> for this project if you think of some more...
>>
>> Jim
>>
>> On Thu, Jun 23, 2022, 23:52 Jim Klimov <jimklimov+nut at gmail.com> wrote:
>>
>>> Hello all,
>>>
>>>   After a hectic month in private life, as a byproduct I've got a viable
>>> merger of last released NUT 2.6.5 based Windows-ready codebase (thanks to
>>> the giants active a dozen years ago, on whose shoulders I stood today) and
>>> modern 2.8.x/master, fixing the merge conflicts and build warnings. Some
>>> details were tracked in discussion of
>>> https://github.com/networkupstools/nut/issues/5
>>>
>>>   There are caveats, e.g. in a few files code was just hidden by
>>> `#ifndef WIN32` so making it "appear" would be a future trick, and some
>>> "silly" fallbacks for missing methods were hacked to make it build but
>>> probably are not thread-safe etc... but at least binaries do appear and
>>> some do run without crashing on Windows - e.g. usbhid-ups and nut-scanner
>>> did see my test UPS. Fixes originally made for libusb-0.1 were applied to
>>> libusb1.c too, but not tried yet.
>>>
>>>   Builds are possible, mostly scripted and documented, see:
>>>
>>> * `docs/config-prereq.txt` and `ci_build.sh` for MSYS2 (includes MinGW)
>>> natively on Windows,
>>> * `scripts/Windows/README` and a build script nearby for using mingw
>>> cross-building packages on Ubuntu Linux.
>>>
>>> Both of these produce lots of standalone usable binaries installable as
>>> a typical NUT directory tree, which (with copies of DLLs for third-party
>>> projects) "just work".
>>>
>>> The adventure starts with:
>>>
>>> :; git clone -b Windows-v2.8.0-1 https://github.com/networkupstools/nut nut-win
>>>
>>> I really hope that the community members more interested and better
>>> versed in the platform can pick it up from here, to discover and fix the
>>> missing and flawed bits, make sense of the installer, etc. and eventually
>>> make this codebase part of common NUT, multi-platform as it is.
>>>
>>> Sone points of interest OTOH:
>>> * c++ and a few drivers are currently effectively "neutered"
>>> * fcntl() code to avoid FD leaks to forked children, is it doable on
>>> Windows?
>>> * loading dlls from one dir, without copies near every exe (see common.c)
>>> * automatically tracking major version number X (from
>>> client/Makefile.am) for LTDL discovery of libupsclient-X.dll without
>>> hardcoding it
>>> * localtime_r, gmtime_r use ugly fallbacks where unavoidable
>>> * usb close_dev() crashes
>>> * not all dependencies were tried, probably more build warnings are
>>> lurking to clean up
>>> * installer not investigated
>>> * code mostly looks at "WIN32" macro as a big switch; there should be
>>> more specific configure-script tests for different versions, toolkits,
>>> build envs, IDEs... that are possible. Supported or not, WIN XP may still
>>> be a big thing...
>>> * clean up what `make install` does (e.g. no systemd/SMF on win)
>>> * automate copying third-party dlls for `make install DESTDIR=...`
>>> (recursive ldd?)
>>> * make sure that Linux/Mac/Solaris/BSD/... builds from this branch are
>>> not broken by that big code merge.
>>>
>>> On my side, curiosity is satisfied, itch scratched and bogus achievement
>>> achieved, so I plan to rest and then do other things. Really looking
>>> forward to you the reader to make the next iterations.
>>>
>>> When this codebase gets "good enough" to at least not fail to build
>>> against more and more third-party projects, I'll look at covering this in
>>> NUT CI so it does not regress with future evolution. This milestone is
>>> actually already viable now, just I'm leaving for vacation :-)
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20220903/2c9cbeaf/attachment.htm>