| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
| |
In general, simplify Toolchain a bit. This is done in preparation for
merging project.boost.toolchain, project.cmake.toolchain and
project.toolchain.
|
| | |
|
| |
|
|
|
| |
This is to facilitate testing mostly, but still required substantion
refactoring.
|
| |
|
|
|
|
| |
The official website now links to jfrog.io:
https://groups.google.com/g/boost-developers-archive/c/vxnAnvG7MCo?pli=1
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Logging command line arguments before parsing them is a bit excessive.
|
| |
|
|
| |
The extremely convoluted BoostBuildToolset situation is no more.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
There were two problems:
* On Windows, VS 2019 defaults to x64 while VS 2017 defaults to x86.
* Too much focus on x86(-64) might mean that building stuff on ARM can
become difficult.
These were all addressed by adding a new platform 'auto'. On Windows,
it defaults to picking either x64 or x86 (depending on the host arch)
for both Boost and CMake. On Linux, it lets the compiler decide what
arch to target.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
