PVS-Studio is a tool for detecting bugs and security weaknesses in the
source code of programs, written in C, C++, C# and Java. It works under
64-bit systems in Windows, Linux and macOS environments, and can analyze
source code intended for 32-bit, 64-bit and embedded ARM platforms.
https://www.viva64.com/en/pvs-studio/
It's very easy to setup and run headless on Linux; although on Windows I
couldn't find instruction describing how to automate the install.
It quickly generates a relatively unique set of issues versus those
reported by Clang's and Coverity's checkers, so it's valuable in that
regard.
Output can be customized in various formats (stdout, gcc-error format,
or HTML), and it produces a nice summary of results that (for a later PR)
we can capture and compare against a maximum warning count similar
to our other checkers.
This PR generates a full HTML report with embedded source snippets,
which are uploaded as a zipped asset.
GitHub's ongoing issue of limitting the cache size has recently
been fixed (https://github.com/actions/cache/issues/6), so this
PR create a combined Clang+GCC cache for separate 32-bit and 64-bit
architectures under Windows.
Also re-order to perform shellcheck first because it
requires the least installation work compared to pylint
and markdownlint. The reason being if we're going to fail
during shellcheck, then we fail faster (and leave heavier
tasks for further down the line).
With SDL2 in place, the silent dependency on libpng12 on Ubuntu 16.04 is
now gone. Unfortunately, development packages for libpng16 are named
differently for Ubuntu 16.04 and 18.04, so we can't add new package to
the global list.
An unfortunately pattern has emerged where Chocolately's repository
servers have been offline or returning error-codes at roughly
5am GMT.
This commit moves the start inside "office hours" for the
majority of Chocolatey's user-base:
- 9am in California & Vancouver
- 11am in New York
- 4pm in London
- 5pm in Poland and Germany
This fixes the prior logic that relies on the (*)curses library
and header existing in compiler-derived default locations
such as /usr/include, and /usr/lib. However, if the package manager
happens to not install them there, then they will not be found
and the check will fail.
Four scenarios:
1. `./configure` or `./configure --enable-debug=no` produce:
(no mention of debugger; configure continues)
2. `./configure --enable-debug=wrong` produces:
configure: error: --enable-debug=wrong was requested but the value "wrong" is invalid
(terminates with exit code 1)
3. `./configure --enable-debug` produces:
config.h:
defines C_DEBUG 1
With only ncurses library installed:
configure: debugger was requested, finding curses library ...
checking for NCURSES... yes
configure: debugger enabled using the ncurses library
Makefile:
CPPFLAGS = ... -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -I/usr/local/ncurses ...
LIBS = ... -L/usr/local/ncurses -lncurses -ltinfo ...
With only ncursesw installed:
configure: debugger was requested, finding curses library ...
checking for NCURSES... no
checking for NCURSESW... yes
configure: debugger enabled using the ncursesw library
Makefile:
CPPFLAGS = ... -I/opt/ncursesw ...
LIBS = ... -L/opt/ncursesw -lncursesw ...
With only pdcurses isntalled:
configure: debugger was requested, finding curses library ...
checking for NCURSES... no
checking for NCURSESW... no
checking for PDCURSES... yes
configure: debugger enabled using the pdcurses library
Makefile:
CPPFLAGS = ... -I/usr/local/pdcurses ...
LIBS = ... -L/usr/local/pdcurses -lpdcurses -ltinfo ...
Without any curses library installed:
configure: debugger was requested, finding curses library ...
checking for NCURSES... no
checking for NCURSESW... no
checking for PDCURSES... no
configure: error: Package requirements were not met:
<pkg-info prints info about missing package>
(terminates with exit code 1)
4. `./configure --enable-debug=heavy` produces same as above, but:
config.h:
defines C_DEBUG 1
defines C_HEAVY_DEBUG 1
The configure message mentions heavy, for example:
configure: debugger was requested, finding curses library ...
checking for NCURSES... yes
configure: debugger with heavy debugging enabled using the ncurses library
Some files in libs are using C compiler, so we need to make sure build
all flags are set for C as well. Als, add -pipe to avoid temporary
files.
This is intermediary step before merging this step back with build
scripts for other jobs.
Move MSYS2 jobs up (these jobs will be updated often, due to warning
limits), and use the same matrix style as Linux and macOS jobs.
Move MSVC jobs down, so the future release build will be closer to
the end of file.
Name 'visualc_net' invokes old names for Visual Studio
(Visual Studio .NET 2002 or 2003), which has no relation to content of
this subdirectory.
Also, by renaming this directory we mitigate chance, that during
merge-in from svn/trunk git will automatically inject some values from
from upstream, incompatible version of solution files. By sheer
luck this might happen without causing a conflict. Never happened so
far, but there's no point in risking it.
Job uses Ubuntu 16.04 to get the widest compatibiity with Linux
distributions.
Snapshot builds are uploaded as job artifacts, but GitHub Actions do not
allow to specify compression program/params yet (everything is forced
into a zip).
It didn't work. Coverity classifies all our builds as belonging to the
stream called 'dosbox-staging' and there's no option to change it.
This reverts commit e86e6e353e.
Details at: https://scan.coverity.com/dashboard
The Coverity software (Roughly 1.5GB worth unpacked from a tarball)
can only be downloaded from an authentication web sessions, so I've
uploaded it to my Google drive and use 'gdown' to pull it inside
the workflow. This sounds ugly, but it's not too bad: Coverity last
updated their software nine months ago, so this will be a once-a-year
change, maybe twice.
The Google drive ID, SHA256 checksum, and other specifics are all
variables at the top YAML, so they're easy to adjust when Coverity
makes their next update. The download, extraction, and sha256
verification are all done in parallel via pipes, and extracting to
/dev/shm. It should be pretty quick. Edit: it is; 4 seconds.
To keep the tarball small, I remove unecessary bits (but this is
optional), before tar & zstd compressing it:
``` bash
rm -rf closure-compiler jars jdk11 jre node support-angularjs
cd bin
rm *java* *js* *php* *python* *ruby*
```
