Heads-up: A community member had good progress in
https://github.com/networkupstools/nut/issues/1690#issuecomment-1301824123
to properly see an USB UPS.
This effort is becoming more viable over time... :)
Jim
On Sat, Sep 3, 2022, 17:25 Jim Klimov <jimklimov+nut at gmail.com> wrote:
> 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/20221103/3bf3d9a6/attachment.htm>