| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
The weird magic going on in the ci-{boost,build} scripts is honestly too
weird. With hindsight, it seems to me that it's much better to just
build a project with the same command during a CI run as when developing
locally.
Plus, I haven't really used either Travis or AppVeyor in quite some
time, so this code was mostly untested really.
|
| |
|
|
| |
Accordingly, rename ci-cmake to ci-build.
|
| |
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
Also, get rid of mentions of Visual Studio versions lower than 2010.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
It should help running the scripts on Windows, where the .py extension
is associated with the Python interpreter.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Using different ones was quite weird to begin with.
|
| | |
|
| |
|
|
| |
It's now <source directory>/../build for consistency.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|