There is too much cruft to wade through to find compiler warnings.
I check these once in a while for all compilers.
We could alternatively use -Werr, but at the risk of more broken builds.
It's useful to see the configure step by itself, so split it out
from the installation of prerequisites.
The make install is verbose, put it in it's own step
Move checking of the errors test-suite and ccache checks from
the Build to Test step.
This seems to be broken and sporadically results in "Text file busy"
errors when the tests are run actually in parallel, as is the case in
GitHub CI environment.
Don't add the builds known/allowed to fail and don't add all the
variations of Python builds, there are just too many of those, but do
add mostly all the rest, with the exceptions below:
Builds using JavaScript backend with node <= 10 had to be disabled as
well, as they just seem to be broken and there is no real motivation in
supporting these ancient versions.
Builds using D can't be run currently due to incompatibility between the
ancient dmd version being used and the earliest support Ubuntu version
(18.04) on GitHub Actions and not supporting newer versions in SWIG.
Builds using Scilab had to be disabled as running the test suite
reliably hangs. This would need to be debugged by somebody motivated in
doing it.
Note that some builds need to be run under Ubuntu 18.04 (Bionic) and not
the default 20.04 (Focal) as they use old dependencies that don't exist
in Focal any longer. In the future we ought to switch to using newer
versions of these dependencies.
This results in passing empty argument to configure which, in turn,
triggers "WARNING: you should use --build, --host, --target" from it as
this argument is apparently misinterpreted as the host name.
Executables can't be produced without this option using clang available
under Ubuntu 20.04, as linking fails with a lot of errors of the form
/usr/bin/ld: Swig/wrapfunc.o: relocation R_X86_64_32S against `.rodata'
can not be used when making a PIE object; recompile with -fPIE
They are supposed to be set to gcc-$GCC and g++-$GCC respectively, if
the suffix is defined, so do it.
Also use "compiler", rather than "CC", in the matrix for consistency
with .travis.yml and to avoid confusion between this property, which may
be empty, and CC environment variable, which is supposed to be always
defined.
Finally, show the path and the version of the compiler being used: this
was also done under Travis CI and there doesn't seem to be any reason
not to do it here.
There doesn't seem to be any good reason to use per-language caches, as
there are files that are common to all languages.
But we do want to use different keys for the different compilers and
even different compiler versions, as they yield different results when
compiling the same code.
Set the PATH to include the ccache directory for the subsequent steps,
including the "build" one, rather than only setting it locally for
configure, as this didn't have much effect at all.
Follow the convention of the GitHub built-in steps, such as the first
"Set up job" one and use capitalized verbs in imperative mood rather
than a mix of non-capitalized verbs and nouns.
This is a purely cosmetic change.
Bash is used by default under all platforms we're going to support here,
so there is no need to specify it explicitly. Moreover, by default the
appropriate shell options (such as "pipefail", as well as "e") are used,
and there is no need to override them.
There doesn't seem to be any reason to make them step-specific, so
simplify the workflow by doing it once and only once at the job level.
No real changes.
Don't rely on the auto-generated names which are not very useful: e.g.
currently something like "build (1, python, 3)" is shown, while this
commit changes it to just "python3" which is both shorter and more
readable.
This makes the matrix more compact, as we don't need to specify the OS
for the majority of the field (all of them now, but we'll add builds
using "macos-N" later, so it will still be necessary for some of them),
and the builds more stable than using which the current latest Ubuntu
version is.
Note that if we decide to do something for the docs later (e.g. run a
spell checker on them), it should be done in a separate workflow and not
in this one.
