| Commit message (Collapse) | Author |
|
The weird magic going on in the ci-{boost,build} scripts is honestly too
weird. With hindsight, it seems to me that it's much better to just
build a project with the same command during a CI run as when developing
locally.
Plus, I haven't really used either Travis or AppVeyor in quite some
time, so this code was mostly untested really.
|
|
Accordingly, rename ci-cmake to ci-build.
|
|
Accordingly, rename cmake-build to project-build.
|
|
|
|
You can now use something like msvc-141, vs-2017, etc.
|
|
|
|
|
|
|
|
This is a stupid workaround for testing other CI systems on GitHub
Actions.
|
|
Logging command line arguments before parsing them is a bit excessive.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
OK, this is epic. I was basically just trying to a) support Clang and
b) add more test coverage. _THREE MONTHS_ and a few hundred CI runs
later, this is what I came up with. I don't know how it ended up being
what it is, but here we go.
Some highlights of the changes:
1) CI builds has been moved to GitHub Actions,
2) the entire notion of a toolchain has been reworked; it now supports
Clang on all platforms.
* .github: this directory contains the GitHub Actions workflow
scripts/actions. In the process, I created like 6 external GitHub
actions, but it's still pretty massive. An upside is that it covers
much more platform/toolchain combinations _and_ check a lot of the
expected post-conditions. TODO: .ci/Makefile is obsolete now, as well
as .travis.yml and .appveyor.yml.
* common.cmake: added Clang support. In the process, a great deal has
been learned about how CMake works; in particular, static runtime
support has been reworked to be more robust.
* project: the entire notion of a "toolchain" has been reworked.
Instead of a measly --mingw parameter, there's now a separate --toolset
parameter, which allows you to choose between GCC, Clang, MSVC, etc.
Both Boost and CMake build scripts were enhanced greatly to support
Clang and other toolchains in a more robust way.
|
|
I.e. it used to be just C:\projects instead of C:\projects\build on
AppVeyor.
|
|
|
|
|