| Commit message (Collapse) | Author |
|---|
|
|
|
Accordingly, rename cmake-build to project-build.
|
|
It doesn't make a lot of sense for the build dir argument to be
optional. There's still a placeholder you can use to build in a
temporary directory.
|
|
On Windows 2022, MinGW now links to api-ms-win-crt-* libraries; keeping
track of that becomes too burdensome, so I'll switch to a black-list of
libraries rather than a white-list.
|
|
Apparently, MinGW doesn't link to either ucrtbase.dll or msvcrt.dll at
all on Windows.
|
|
|
|
|
|
|
|
This is to facilitate testing mostly, but still required substantion
refactoring.
|
|
|
|
|
|
|
|
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.
|
