Repository navigation
Set up Travis CI testing for more compiler implementations and C/C++ standards #823
Description
As discussed in #810 (comment) we have a number of coding issues hidden into warnings, ultimately different ones if we variate the requested C/C++ standard implementation. Currently we build on Travis CI with whatever compiler and its options are the default for distribution Travis offers at the time of build, and without hiccups on warnings.
The idea proposed here is to utilize Travis CI ability to run jobs allowed to fail (so no direct impact on passing-or-not CI tests) with our matrix of CC, CXX, CFLAGS and CXXFLAGS definitions to test with different versions of gcc, clang, maybe others and with different C standards inside that, with and without required failure on warnings.
When a target combo becomes green, we can mark it as no longer allowed to fail, to ensure that future contributions do not break it again (non-regrassion).
Overall this should make it easier for developers to update the NUT codebase and see potential issues introduced by their changes, without noise from already existing problems that this effort aims to ultimately eradicate. This would allow us as a community to be more confident about the quality of code even before we get it to testing against real hardware devices, media, protocols and third-party libraries and OS code involved. We'd be doing the best we can, on our side of equation :)
Activity
jimklimov commentedon Oct 8, 2020
CI Enhanced.
jimklimov commentedon Oct 9, 2020
For posterity, the mechanism added with PR #824 allows to track on Travis CI that new contributions do not break existing working platform cases and whether they fix cases currently broken (then we can comment away the test setup's line in
allowed_failureblock).For developers with environment set up to compile NUT, the
envblock definitions of the case can be copy-pasted to terminal (and adapted for different compiler flags or versions) so they can check on their workstation what works and what does not, using the sameci_build.shscript, e.g.:This would help extend the non-regression platform support as more compilers are getting tested. One obvious and useful case not covered now could be adding builds on MacOS.
Per recent discussions, the codebase should work in a C99+ capable compiler, and there may have been some project communication in the past about that, although nothing indicates that requirement/expectation in current codebase except one
configure.ac:AC_PROG_CC_C99line.In experimental practice, at least on Linux compilations with both gcc and clang requiring any strict "c" standard (
-ansiaka-std=c89, c99, c11...), fail with a number of undeclared routines and/or data types which probably is an issue between system headers and GNU extensions. For gnu99 and gnu11 modes without warnings builds succeed; with warnings there is a handful of issues yet to address to be clean. gnu89 seems to need significant effort to be warning-less and not sure that is warranted at this time.jimklimov commentedon Oct 10, 2020
One more point for inspiration about compilers to try, including some MacOS combos:
Also for more platform support (though maybe makes sense to somehow limit the use of constrained resource to building a few combinations of these and only for master branch increments by default?):
See about explicitly 32-bit builds to check for wrong assumptions about short/long/fixed int variables.
In ci_build.sh script, re-run to check more configure options and/or "magic define's" that can impact which code path is built (e.g. openssl vs nss vs no crypto).
If NUT4Win effort is eventually revived, Travis brewing support for Windows workers may become of interest:
169 remaining items
configure.ac: quiece -Wincompatible-function-pointer-types-strict for…
tools/nut-scanner/nutscan-display.c: fix the order of calloc() parame…
docs/developers.txt: clarify pragmas in switch/case/default vs. enum [n…
Reconcile int-ish data types with formatting strings [networkupstools…
Reconcile int-ish data types with formatting strings [networkupstools…
drivers/*, clients/*, common/*: fix pathname budders to be NUT_PATH_M…
common/common.c, drivers/powerp-txt.c, drivers/nutdrv_qx.c: cast char…
drivers/*, clients/*, common/*: fix pathname budders to be NUT_PATH_M…
common/common.c, drivers/powerp-txt.c, drivers/nutdrv_qx.c: cast char…
*.c: fix use of non-const char* with strstr() and strchr() return val…
*.c: fix use of non-const char* with strstr() and strchr() return val…
*.c: fix use of non-const char* with strstr() and strchr() return val…
*.c: fix use of non-const char* with strstr() and strchr() return val…