cmake-common - Utilities to help develop C++/CMake projects

	Commit message (Collapse)	Author	Age
*	project: minor refactoring	Egor Tensin	2021-03-20
\|
*	project.platform: add platform 'auto'	Egor Tensin	2021-03-20
\| \| \| \| \| \| \| \| \| \| \| \| \|	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.
*	grammar	Egor Tensin	2021-03-15
\|
*	move large in-code comments to docs/	Egor Tensin	2021-03-14
\|
*	project.boost.download: create missing directories	Egor Tensin	2021-03-14
\|
*	fix PyLint warnings	Egor Tensin	2021-01-17
\|
*	GIANT CLUSTERFUCK OF A COMMIT	Egor Tensin	2021-01-17
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	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.
*	README: elaborate	Egor Tensin	2020-10-18
\|
*	project.boost.download: add dest_dir parameter	Egor Tensin	2020-04-04
\|
*	project.boost.download: --unpack = --cache if specified	Egor Tensin	2020-04-04
\|
*	project.boost: retry downloads	Egor Tensin	2020-03-31
\|
*	project.boost.build: switch to --layout=system	Egor Tensin	2020-03-30
\|
*	project.cmake: make it --platform aware	Egor Tensin	2020-03-30
\|
*	project: code style	Egor Tensin	2020-03-30
\|
*	project.boost: support --mingw for Travis/AppVeyor	Egor Tensin	2020-03-30
\|
*	project.build.build: more restrictive defaults	Egor Tensin	2020-03-30
\|
*	project: minor-ish refactoring	Egor Tensin	2020-03-30
\|
*	project.boost: first-class MinGW-w64 support	Egor Tensin	2020-03-29
\|
*	project: add os.py	Egor Tensin	2020-03-29
\|
*	fix READMEs, code style, etc.	Egor Tensin	2020-03-29
\|
*	project.boost: -d0 by default	Egor Tensin	2020-03-29
\|
*	project.boost: factor out everything else	Egor Tensin	2020-03-28
\| \| \| \|	I finally snapped. This starts to resemble sensible structure though.
*	project.boost: factor out BoostVersion	Egor Tensin	2020-03-28
\|
*	project.boost: factor out Configuration/Platform/Linkage	Egor Tensin	2020-03-28
\|
*	WIP: restructure	Egor Tensin	2020-03-28
	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.