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).
This way there's no need to prepend every line in build job with a path
to MSYS2-installed bash, and deal with problems related to escaping
embedded shell invocations.
The commit makes the following changes:
- The package listing script now requires the user specify which package manager
they're using. This approach resolves the ambiguity if a system has more than
one package manager (ie: macports & brew)
- Adds packages for Fedora, RedHat/CentOS, Arch, and OpenSuse
- Eliminates unecessary code in the package manager script
(more can be eliminate at the expense of complexity)
- Made a couple minor fixes to the build script
- Tried to further "standardize" the workflows as follows:
- names are Compiler Version (Environment)
- Sorted them alphabetically in their respective YAMLs
- Minor spacing adjustment to align values (where it makes sense)
- Dropped quotes around some of the string values because I'd
rather our YAML be consistent and propper instead of changing our
YAML to suite the limitations of an editor (can a different plugin
or better parser be used?)
- Added macOS workflows for Homebrew and MacPorts, both ready to
go and tested, but with the build step just commented out
This change makes a couple changes to the CI workflow:
- Adds more compiler coverage:
- gcc to MacOS (see note below)
- 32 and 64bit gcc and clang to Windows
- With more builds, this separates them into per-OS workflow YAMLs
(laying the foundation for more build environments: BSD? DOS? ... )
- Moves all functional commands from GitHub-syntax-YAML into scripts,
which (besides eliminating repeated code), now serve a dual-purpose
of being runnable outside of GitHub.
- One script takes care of listing dependent packages for the given
runtime environment
- Another script takes care of configuring and building
These scripts can be leveraged by a nightly build & asset generator in
the future.
Note: adding GCC to MacOS is now "correct" from a build perspective,
however to keep this PR focussed on the CI workflow I have not included
the coreMIDI / AppleBlocks code-fixes here (so for now, the gcc macOS
builds will fail; we will merge the coreMIDI / AppleBlocks later
depending on how upstream wants to handle it).
log-env.sh is cross-platform (works on Linux, MacOS and Windows)
log-env.ps1 is Windows-only and requirs specifying pwsh shell, but
provides some Windows-specific information, that might be useful e.g.
for MSVC builds.
DOSBox maintainer expressed a concern about mail being stored verbatim
in the source code. SourceForge does not forward messages to the
real mailing addresses by default, therefore it's rather pointless to
target them for spamming nowadays, but git-svn can easily take input
from as script, so let's just replace the static file.
This format makes it easier to correlate SVN revisions with Git commits
for users who depend on such behaviour.
Usual caveats around working with SVN revision numbers apply: they do
not identify patch/commit, they identify a change in the state of whole
SVN repository (i.e. single revision might span multiple paths,
including multiple "branches" or "tags" or "projects").
Do not depend on SVN revisions to uniquely identify a commit created by
an SVN user (especially for scripting) - you need a tuple <SVN path,
SVN revision> for that. It's easier to identify a commit by git hash
(this script displays shortened hash in a first column).
Upstream svn/trunk just introduced a bunch of new warnings.
Piggy-back change to interpret "From:" lines in SVN to be imported as
proper authorship information.
Implements new script (count-bugs.py) for peeking inside clang static
analyzer's report and print just a summary.
If number of detected bugs goes beyond the limit, script will return
with error code 1, thus failing the CI run. The upper limit is set to
113, which is current result of static analysis in our CI environment
(local run is likely to indicate different number); upper limit will
be updated in time, as issues get fixed or new compiler (detecting more
bugs) will be introduced.
This commit includes also slight modifictaions to count-warnings.py
script, to keep the both scripts outputting in similar format.
This way it will be possible to prevent users from introducing new
warnings. As new fixes will be upstreamed, the maximum limit of
allowed warnings should be taken lower and lower, so this script
could be eventually replaced by -Werror.
