* Switch compiler builds and tests to GitHub actions
* Expose ${cc} in ocamltest
* Allow lib-bigarray-2/bigarrfml.ml to run on 32-bit
* Simplify environment variables passed to scripts
* Reduce matrix to 3 builds
* Move minimum build into Jenkins other-configs
When building for the first time, the only requirement is that generated
header files have been built (jumptbl.h, version.h and opnames.h).
Detailed dependency information is only required when headers have been
edited.
COMPUTE_DEPS in Makefile.config controls whether C dependency
information should be generated on a per-file basis. This variable is
controlled by a new --disable-dependency-generation in configure which
is enabled for Git checkouts and disabled for tarballs (i.e. releases).
The Microsoft C compiler (cl) cannot generate dependencies in a
consistent way which we can consume, so for a Git checkout configure
searches for an additional C compiler in order to compute dependencies.
This is obviously not required for a user-build.
As a result, the MSVC port can now safely run make alldepend, since only
OCaml dependency information is committed to the repo after this change.
CI does not need to waste time testing the dependency information,
because it only tests a single build. A single Travis job has been added
which tests the build system code to generate the dependency information
(and provides a single `make -j` run in CI, although Inria's CI also
tests parallel building continuously).
Travis CI (Continuous Integration) tests provide feedback to people
contributing patches and pull requests. There has long been a test
checking that the Changes file is modified by the PR (along with
a test checking that the testsuite is modified), but it was marked
optional (`allow_failures`) and not reported in a clear way at all.
(In theory all user-visible or contributor-visible changes should get
a Changes entry. There are some cases of minor changes, or changes
that affect features not present in a released version, where not
having a dedicated changelog entry is ok.)
There are two cases where forgetting to include something in the
Changes has been problematic:
- inline records were originally not part of the 4.03 Changelog
(we caught the error as I gave a talk on new 4.03 features and
Alain gently asked why I left inline records out of the discussion)
- recently GPR #674 was forgotten from the Changelog
If we make the Change mandatory in the CI, it is because without it
there is no clear notification than it fails. It does not mean that
having a Changelog entry is now mandatory, and it's just fine to keep
deciding on a case-by-case basis not to have an entry. It's just that
we would make that choice voluntarily, instead of out of distraction.
David Allsopp
Gabriel Scherer
YOSHIMURA Yuu
zapashcanon
Sébastien Hinderer
Florian Angeletti
Damien Doligez
Pierre Chambart
Thomas Gazagnaire
Damien Doligez
Mark Shinwell