aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/project/ci/boost.py (unfollow)
Commit message (Collapse)Author
2021-04-13fix PyLint warningsEgor Tensin
2021-04-13project.ci: hide the --hint parameterEgor Tensin
2021-04-13project.ci: add --hint parameterEgor Tensin
This is a stupid workaround for testing other CI systems on GitHub Actions.
2021-04-13remove excessive logging & obsolete project.ci.* packagesEgor Tensin
Logging command line arguments before parsing them is a bit excessive.
2021-03-13project.ci: cache Boost downloadsEgor Tensin
2021-01-25project.ci: auto-fill --toolset from environmentEgor Tensin
2021-01-25project.ci: auto-detect CI systemEgor Tensin
2021-01-17GIANT CLUSTERFUCK OF A COMMITEgor Tensin
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.
2020-04-04project.boost.download: add dest_dir parameterEgor Tensin
2020-03-30project.ci: dedupe codeEgor Tensin
2020-03-30project: code styleEgor Tensin
2020-03-30project.boost: support --mingw for Travis/AppVeyorEgor Tensin
2020-03-29fix READMEs, code style, etc.Egor Tensin
2020-03-28project.boost: factor out everything elseEgor Tensin
I finally snapped. This starts to resemble sensible structure though.
2020-03-28project.boost: factor out BoostVersionEgor Tensin
2020-03-28WIP: restructureEgor Tensin
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.
2020-02-01boost/build/ci: build in predefined directoryEgor Tensin
2020-01-09better usage messages & READMEsEgor Tensin
2020-01-08boost/build: add --runtime-linkEgor Tensin
This time with more safety checks.
2020-01-07boost/build: add the --link parameterEgor Tensin
2020-01-07AppVeyor: fix boost/build usageEgor Tensin
2020-01-07AppVeyor: add some tests for boost/buildEgor Tensin
2020-01-07boost/build/ci: fix module import errorsEgor Tensin
2020-01-03rearrange all files completelyEgor Tensin
2019-12-16ci: fix a bug in case no positional parametersEgor Tensin
2019-12-15ci: minor script enhancementsEgor Tensin
2019-12-15build: clean up silly cmd line paramsEgor Tensin
They were just plain synonyms for CMake flags, barely had any value.
2019-12-14boost/build.py: split into subcommandsEgor Tensin
2019-12-13build/ -> ci/Egor Tensin
2019-12-13build/boost: add generic build.py scriptEgor Tensin
2019-12-10add simple build scriptsEgor Tensin
They're intended to replace my build.sh (for Travis) and build.ps1 (for AppVeyor) scripts to call CMake in a platform-independent manner.