| Commit message (Collapse) | Author |
|
|
|
This is to facilitate testing mostly, but still required substantion
refactoring.
|
|
|
|
|
|
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 finally snapped. This starts to resemble sensible structure though.
|
|
|
|
A stupid attempt to reduce code duplication led me to believe that all
the scripts could use _a bit_ of refactoring.
This is going to be a major pain (factoring out all the things), which
I'll take gladly.
All the links and usage examples are broken right now, but nobody cares,
so whatevs.
|
|
|
|
|
|
This time with more safety checks.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
They were just plain synonyms for CMake flags, barely had any value.
|
|
|
|
|
|
|
|
They're intended to replace my build.sh (for Travis) and build.ps1 (for
AppVeyor) scripts to call CMake in a platform-independent manner.
|