Merge Windows support branch based on NUT v2.8.x era code back to master #1611
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… fail if UPSD is not running
…rack (troubleshoot)
…ths while testing
…t more prereq builds
…config for libgd (fails due to ICU so far)
…to system location
autoconf fudges paths for DESTDIR if they are based in '${prefix}'
but ones hardcoded for auglensdir are not there
…retry with static-linking assumption for net-snmp
Windows v2.8.0 branch update to minimize differences vs. Master branch (and apply some fixes from it)
…tion ci_build.sh integration
|
This pull request fixes 4 alerts when merging 51f5a12 into 2ce9dfa - view on LGTM.com fixed alerts:
|
|
✅ Build nut 2.8.0.29-master completed (commit c63916cf92 by @jimklimov) |
…ck strcasestr() implem
configure.ac, drivers/libusb0.c: fix detection of strlwr() and fallback strcasestr() implem
…libusb-0.1 variant
…libusb-0.1 variant
Typo fix for `ifdef HAVE_USB_H` (libusb-0.1 header)
Typo fix for `ifdef HAVE_USB_H` (libusb-0.1 header)
Detect configure script error: Neither HAVE_USB_H nor HAVE_LUSB0_USB_H is set for the WITH_LIBUSB_0_1 build
Detect configure script error: Neither HAVE_USB_H nor HAVE_LUSB0_USB_H is set for the WITH_LIBUSB_0_1 build
Windows branch: fix builds against libusb-win32
configure.ac, drivers/libusb0.c: fix detection of strlwr() and fallback strcasestr() implem
m4/nut_check_libusb.m4: when on Windows, prefer libusb-0.1 [#1507]
|
This pull request fixes 4 alerts when merging 72811e3 into 4837d42 - view on LGTM.com fixed alerts:
|
|
This pull request fixes 4 alerts when merging ffffd6c into f6a0fbb - view on LGTM.com fixed alerts:
|
|
This pull request fixes 4 alerts when merging 295f3b7 into 532bada - view on LGTM.com fixed alerts:
|
Revisit NUT for Windows v2.8.0 branch after upslog update
|
This pull request fixes 4 alerts when merging ef527f6 into 532bada - view on LGTM.com fixed alerts:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As discussed in countless issues (starting as early as #5) and PRs over the years -- some seen via Windows label -- as well as mailing list discussions, at some point in the past NUT for Windows was "a thing", complete with MSI based installer... There are still questions and suggestions floating around, regarding fixes to that installer, such as #1050 updated not so long ago.
That effort was pursued on a side branch in Git which withered since approx ~2013-2015, with NUT 2.6.5-7 as a last used baseline.
During this year that codebase was picked up and rebased, adapted or refactored for evolution that happened in the NUT master branch up to and including the 2.8.0 release -- primarily advances in "fightwarn" areas for a cleaner codebase and respectively a huge cross-platform CI buids matrix and integration tests to make sure there are no regressions added with new contributions, as well as added libusb1 and modbus support, revised logging and daemon startup processing, etc.
There should not have been any significant functional changes to Windows-specific implementation compared to the decade-old achievements, other than improvements shared with the NUT evolution and possible changes due to refactoring/adaptation (and fixing warnings that arose in Windows builds). Architectural choices made over time are seen in the branch's Git history (e.g. going running daemons as standalone services and back to an umbrella service; pipe comms vs signals; forking or not upsmon; effective lack of user account awareness) with the last posted variant from ~2013-2015 publications remaining at Git HEAD. Great thanks to the giants on whose shoulders this PR stands today!
The proposed codebase is known, documented, and regularly CI-tested to cross-build in Ubuntu/Debian Linux mingw packaged environment (x86_64 and i686), as well as semi-natively in Windows with MSYS2/MinGW (x64 regularly, and some experiments seemed successful with UCRT and x86).
In recent weeks, many of the changes initially proposed in Windows-branch development which made sense regardless of the platform were posted to master as separate PRs (with latest spree going from PR #1524), with the goal of ensuring that proposed addition of Windows-specific support to main NUT codebase does not unexpectedly taint the stable "POSIX codebase".
In particular, lots of issues were exposed and fixed in PyNUT and nutclient libraries, as well as bugs were caught in Windows branch codebase (and later fixes confirmed) by the
make check-NITtests.This way, the majority of Windows-specific codebase is separated by
#if(n)def WIN32and I tried to generally keep the differences to the minimum (sharing the code both platforms can use). Notable outliers are:TYPE_FD*macros and respectiveERROR_FD*values andVALID_FD*()/INVALID_FD*()clauses. In POSIX builds they all remain the same (intoriented, negative values are invalid), but in Windows codebase they are all different due toHANDLE,SOCKET, or pointer to a special structure in NUT codebase made for serial port handling (TYPE_FD_SERin serial and SHUT drivers). In some sources however it seems the work with sockets is well abstracted bywincompat.hso well that theintremained in place for both codebases [Revise use of struct pollfd, sock_fd and ups->fd (UPSCONN_t::fd) for WIN32 branch #1592]configure.acfor finer-grained method and data type availability checks, and respective#if (!)HAVE_... #includechanges/additions in some sourceslibregexgot used for USB builds - not sure OTOH if it is redundant vs. some other regex implementation we use elsewhere? [Revise use of libregex in Windows branch #1608]close_dev()crashes when tearing down a NUT driver on WIN32 (at least, usbhid-ups with libusb-0.1-compat) #1486]upsdebugxlogging) in methods written "twice" (upsd.c, upssched.c, ...)Current Windows-oriented code has some known incompleteness - some such issues were tagged with Windows-not-on-par-with-POSIXAspect of Windows builds known to be dysfunctional compared to POSIX builds; fix needed to be on par
label, and it did not explore revival of MSI packaging. For easier testing however, a
make install-win-bundlerecipe was added to help prepare an installation proto area (same as usually done for packaging) complete with DLLs made from open-source prerequisites in the MinGW environment used.In fact, the ability to build and test this codebase all across our multi-platform board without warnings and errors, as well as confinement of Windows-specific changes in most of the places, makes me fairly confident that at worst, merging this PR won't break current primary NUT build targets - and would help the Windows codebase not bit-rot for another decade. That said, attentive eyes are welcome to add even more peace of mind. And later on, here are lots of loose ends (like commented/ifdefed-away swaths of code) to tie up, so we can make packaged NUT for Windows builds a reality again! ;)