| Commit message (Collapse) | Author | Age |
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
I actually tried running this w/ Python 3.6, and it's just a PITA. A
couple of later features are already in use.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
For some reason, when using workflow_run: trigger, it gets triggered on
any listed workflow, not on all of them as I would expect.
|
| | |
|
| | |
|
| |
|
|
| |
setuptools of the required version doesn't support 3.8.
|
| | |
|
| |
|
|
| |
At least I hope that it is.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This repo literally started with common.cmake. However, I think that in
this day and age, it is, to put it mildly, outdated. Feature by feature:
* The C++ standard is better defined on a per-project basis, and it's
very easy. Frankly, I'm surprised GCC still (as of March '26) defaults
to something pre-11 (or at least I think it does).
* The warning options are, again, very easy to do on a per-project
basis, and perhaps they should be defined there.
* The Windows-only defines (NOMINMAX, etc.) are, again, very easy to
define on the project level, and don't warrant a separate file.
* The static runtime thing is more tricky. I use static runtime linking
on Windows only, basically. And since about 3.15, it supports
CMAKE_MSVC_RUNTIME_LIBRARY, which can set up the linking without my
help. I don't care about the older versions enough to keep maintenance.
* Symbol stripping is better done when calling `cmake --install --strip`
in modern CMake version. Otherwise, it's a simple compilation flag for
Release builds.
* Installing PDBs does require some trickery though. It's simple enough:
you just call install() with $<TARGET_PDB_FILE> or whatever it's
called.
|
| | |
|
| | |
|
| |
|
|
|
| |
To be specific the "dynamic" example is the new "simple". I don't need 3
basic example projects, one is enough.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
In addition, command line arguments have been overhauled for sanity and
consistency.
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
egor-tensin/dependabot/github_actions/egor-tensin/cleanup-path-5
build(deps): bump egor-tensin/cleanup-path from 4 to 5
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |\
| |
| |
| |
| | |
egor-tensin/dependabot/github_actions/actions/upload-artifact-7
build(deps): bump actions/upload-artifact from 6 to 7
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 6 to 7.
- [Release notes](https://github.com/actions/upload-artifact/releases)
- [Commits](https://github.com/actions/upload-artifact/compare/v6...v7)
---
updated-dependencies:
- dependency-name: actions/upload-artifact
dependency-version: '7'
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 has been done for the boost example anyway, and I'm planning to do
this.
|
| |
|
|
|
|
| |
Since I've been transitioning to Boost's CMake files, the shortcut where
I just specify LIBRARYDIR & USE_STATIC_RUNTIME doesn't seem to work
anymore, so we're fighting.
|
| |
|
|
|
|
|
|
|
| |
That's part of a global transition aiming to switch to Boost CMake
files. Since 1.70.0, they've been releasing CMake files, which I should
(?) be using. Additionally, modern CMake versions simply deprecate the
FindBoost module (see policy CMP0167), insisting on using the supplied
CMake files. I'll try to continue supporting old Boost versions; let's
see how it goes.
|
| | |
|
| |
|
|
| |
It's not supported on GitHub Actions yet.
|