| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bumps [actions/setup-python](https://github.com/actions/setup-python) from 6 to 7.
- [Release notes](https://github.com/actions/setup-python/releases)
- [Commits](https://github.com/actions/setup-python/compare/v6...v7)
---
updated-dependencies:
- dependency-name: actions/setup-python
dependency-version: '7'
dependency-type: direct:production
update-type: version-update:semver-major
...
Signed-off-by: dependabot[bot] <support@github.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bumps [actions/checkout](https://github.com/actions/checkout) from 6 to 7.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/checkout/compare/v6...v7)
---
updated-dependencies:
- dependency-name: actions/checkout
dependency-version: '7'
dependency-type: direct:production
update-type: version-update:semver-major
...
Signed-off-by: dependabot[bot] <support@github.com>
|
| | |
|
| | |
|
| |
|
|
|
| |
For some reason, when using workflow_run: trigger, it gets triggered on
any listed workflow, not on all of them as I would expect.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
To be specific the "dynamic" example is the new "simple". I don't need 3
basic example projects, one is enough.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bumps [egor-tensin/cleanup-path](https://github.com/egor-tensin/cleanup-path) from 4 to 5.
- [Release notes](https://github.com/egor-tensin/cleanup-path/releases)
- [Commits](https://github.com/egor-tensin/cleanup-path/compare/v4...v5)
---
updated-dependencies:
- dependency-name: egor-tensin/cleanup-path
dependency-version: '5'
dependency-type: direct:production
update-type: version-update:semver-major
...
Signed-off-by: dependabot[bot] <support@github.com>
|
| |
|
|
| |
Why do I even need this? on: push covers everything I need
|
| |
|
|
|
| |
The proper way to do this is to do `cmake --install --strip`, and not
via a function.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This should speed things up. Hopefully I didn't mess it up.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Part of a) simplifying the workflow files and b) reducing the number of
jobs. I'll probably add basic Cygwin jobs later.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
They are stable enough.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
actions/cache@v2 doesn't work on windows-2016 images, since those
contain the GNU tar, which cannot work with \ as path separator. This
was fixed in package @actions/cache v1.0.5, which is used by action
actions/cache@v2.1.4 [1][2].
In addition, it simply couldn't find tar.exe on those images thanks to
my action cleanup-path, which removed the corresponding directory (I
think it was Git's bin/) from PATH. It worked for windows-2019 images
thanks to them containing tar.exe in System32. Solved by turning
cleanup-path into a JavaScript action with a "post" step, which restores
the original PATH value.
[1]: https://github.com/actions/virtual-environments/issues/480
[2]: https://github.com/actions/toolkit/issues/632
|
| | |
|
| | |
|
|
|
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.
|