search

networkupstools / nut

The Network UPS Tools repository. UPS management protocol Informational RFC 9271 published by IETF at https://www.rfc-editor.org/info/rfc9271 Please star NUT on GitHub, this helps with sponsorships!
https://networkupstools.org/
Other
2.03k stars 349 forks source link

Cross-platform build tool/system that works on Windows #1649

Open Anutrix opened 2 years ago

Anutrix commented 2 years ago

Has there ever been thought of moving to cross-platform build tool like scons, gradle, ant, etc. instead of the sh script and Autotools that's currently used. Sh scripts won't natively run on Windows and there are quite some cons of autotools.

Is there already a ticket for this?

jimklimov commented 2 years ago

I suppose gradle and ant (and maven) are java-oriented and so care little for C/C++ builds (and their pkgconfig files, or legacy scripts, or autodetection fallbacks). Not sure about scons, didn't use it.

Maybe cmake could cut it, but would be quite an endeavour and not sure that the dozens of projects that NUT relies on would be esily wrangled to play along.

In fact the core system used in NUT builds is the venerable GNU autotools/autoconf which is cross-platform for decades. And it got NUT all around the server and (POSIX) desktop and embedded world with whatever C and Make implementations they have. Windows was always an outlier of sorts, and just recently came closer into the fold at last. With the likes of mingw, msys, cygwin, git-bash etc. shell scripts are not too unwieldy on Windows either.

If some build scenarios (e.g. VS tooling) would require an alternative set of recipes, someone would have to maintain them in sync with the true cross-platform builds.

If there is a build system that works everywhere (likely cmake of what I hear) - Linux, Solarish systems, BSDs, MacOS, maybe HPUX/AIX still used by some - so there is one set of recipes to maintain, and if you endeavour (or entice someone else) to write something on par with current web of makefiles for libs and docs and programs, which could replace it wholesale - that might be interesting :)

Keep in mind that NUT tries to remain usable on systems still (and already) running, so roughly anything built this millenium (OS version, CPU arch and bitness wise) - if it built/ran NUT before, it should still with new releases. C99, weirdness of embedded, and all that...

The ci_build.sh is recent syntactic sugar to avoid mile-long build option lists for typical dev/CI iterations in a way reproducible easily in a terminal on whatever OS, and to automate some CI scenarios like builds with different SSL and USB implementations.

Anutrix commented 2 years ago

Keep in mind that NUT tries to remain usable on systems still (and already) running, so roughly anything built this millenium (OS version, CPU arch and bitness wise) - if it built/ran NUT before, it should still with new releases. C99, weirdness of embedded, and all that...

Cool. Makes sense. Is there a list of platforms we support officially? If not we should make one. Contributors can add more platforms/OSs they've used and/or tested on.

This might be harder to generalize given how many distributions/flavors of Linux exist but might be simpler/must for Windows platforms. Windows has quite a reputation for breaking compatibility at low level OS APIs(not sure if much of it will affect this project). Windows NT 5.1(Windows XP) and even newer should be our goal for now IMHO(as also suggested in https://alioth-lists.debian.net/pipermail/nut-upsdev/2016-April/007172.html). For older Windows stuff if needed, we can slowly improve compatibility over time.

This will help us decide on choosing an alternative build system or any other Windows tool/library if and when needed in the future.