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*
```
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
- For each OS, builds of the default compiler plus the
latest-supported compilers are run. When multiple operating systems
are supported (such as Ubuntu 16.04 and latest), a build on
the oldest OS using its default compiler is also performed.
- Debug builds are used because they often are more thorough at
detecting coding issues (debug warning counts are higher).
- Runtime dynamic sanitizers are added and serialized per-compiler.
Their build and runtime log-files are xz-compressed, and then
GitHub's asset upload Zips the log directory.
- Each workflow now holds the maximum allowed compiler warnings
per-build, so we can have tighter control of when new warnings
are introduced (that would otherwise pass if still below the
maximum)
- Use of github's new 'cache' feature has been leveraged to restore
the brew, macports, and msys2 environments to eliminate the
lenghthy setup times for those environments. If a new cache
is needed, then we simply increment the cache `key:` value and
the next CI run will archive new caches. (Note that GitHub has a
400MB limit on cache size however they have already said they
are raising it - so we might be able to cache out longest running
job which is MSYS+Clang)
- Where it makes sense, multi-line workflow statements have been
broken out into .github/scripts as files to make the workflow YAML
leaner and more readable, while giving us a richer environment in
the scripts.
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).
GitHub notified me, that they are dropping macOS-10.14 completely, all
users are upgraded to macOS-10.15 and the only valid value in CI jobs
will be macos-latest from now on.
I haven't seen any indication of the same happening for Windows
machines, but GitHub Actions documentation dropped all references to
windows-2016 and windows-2019 - windows-latest seems to be the only
valid value for shared runners from now on.
Ubuntu machines are left as they are (thankfully).
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.
Apt does not have a stable CLI interface, therefore should be avoided in
scripts. Using apt-get should be fine.
Split 'apt-get update' to a separate step. It makes it easier to
check, what mirrors and repositories are being used by CI machines.
Remove SPDX identifier - it's missing from other .yml files (I would
consider these configuration files and not source code, so not covered
by copyright).
Use the same build dependencies for static analysis build as in other
Linux jobs.
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).
