This commit:
- Adds a separate analysis run against the MIRSA (Motor Industry
Software Reliability Association) criteria, which is extremely
thorough. This tally is not summarized or considered fatal to the
workflow. It runs virtually instantly, and the results are very
interesting; however are too numerous to include in our general
analysis (ie: over 13,000 issues).
- Changes the PVS summary script output to a tally-per-file instead
of trying to summarize the nature of the issue, which was mostly
unhelpful without the full text.
- Adds the full list of possible supressible issue to the report
directory, so if further suppressions are needed then these will be
easy to find and use.
- Adds one dr_flac suppression per the resolution here:
mackron/dr_libs#117
Users, who try to compile keep tripping over it, despite documentation
in the INSTALL file. Also, autoconf-archive might be hard to install
for users, who opted not to use MSYS2 and stick to MinGW only.
This commit bundles macros:
AX_CXX_COMPILE_STDCXX (version/serial 10)
AX_CXX_COMPILE_STDCXX_11 (version/serial 18)
When using C++11 code that can possibly throw exceptions (such as
std::make_shared(...) linking libstdc++.a using Clang on MSYS2
will generate errors such as:
libstdc++.a(eh_personality.o): duplicate section
`.rdata$_ZTSSt9exception[_ZTSSt9exception]' has different size
Although potential suggested fixes involve allowing duplicate symbols,
-Wl,--allow-multiple-definition, this solution can introduce unexpected
behavior when one symbol clobbers another symbol.
To solve this, switching to dynamic linking of the libstdc++ library
appears to be all that's needed.
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).
Use the exact formatting suggested in COPYING file.
This change is basically a pretext to trigger a new clean build in
order to check if Coverity is capable of accepting new builds for
analysis finally.
When two files have the same number of warnings, they will appear
in the same order in the summary, making the diff between different
build logs smaller.
Most linters behave this way, so it will fit the users' expectations.
Make -m optional, this makes the script a little bit easier to use.
Behaviour of MAX_WARNINGS and using -1 to disable the check is
preserved.
This works out of the box on Linux and MSYS2, but does not work on
macOS - Xcode supplied make does not support this option, so GNU make is
used instead.
Unfortunately, adding new package on macOS did not invalidate the cache,
this package removes the brew cache from macOS job to avoid this problem
in the future.
Fixes: #53
Until now the build and package scripts have supported
several architectures, compilers, build types, package-managers,
and bit-depth targets.
The code might be maintainable if left as-such, however we have plans
to continue expanding the number of architectures (ARM, PPC, ... ),
operating systems (Android, BSDs, ...), and build variations
amung those.
The scripts (regardless of language) would only grow in complexity
as more variations are added. Thus, we needed a solution that can
scale without adding complexity.
To achieve this, the scripts were refactored as follows:
- all "data" was moved out of code into configuration files
- A back-end "Automator" engine was written to parse the
data based on generic variables fed to it by a front-end
script
- build.sh and list-packages.sh were re-authored as thin front-end
scripts that drive the automator
- Their CLI's were retained so there has been very little change
needed to the CI invocation lines. The only changes have been to
clarify the existing arguments improved based on feedback, ie:
--build-type release, --build-type debug instead of fast, small
This change allows the maximum issues to be passed in as an argument.
If nothing is passed, then the existing build-in maximum is
used.
Retaining the existing built-in value makes sense for home
users to keep track of their local build (otherwise they would have
to remember the prior number of warnings and pass that value
in for subsequent builds).
Motivation: until now the built-in maximum covers the build permutation
that happens to generate the most warnings versus other builds.
In some cases new warnings may not be cause if they elicit a warning
from the lesser-warning build(s) or compilers, but not in the
maximum-warning build.
This change lets us tighten-down the warning uniquely for each build,
so we can be sure all new warnings are flagged to the developer.
Some distributions provide python2 version of pylint package by default,
but all provide pylint for python3 in some package. Python 2 reaches
EOL in few months, so there's no reason to support it.
This prevents our scripts from being accidentally marked invalid due to
language changes between python 2 and 3. Also, newer pylint has nicer
output, that provides exact module filename straight in the warning.
Includes two small scripts: verify-bash.sh for running shellcheck, and
verify-python.sh for running pylint.
.pylint rc files is a default configuration file generated by
pylint 2.3.1, with one change (min-similarity-lines changed
from 4 to 10).
