diff options
Diffstat (limited to '')
| -rw-r--r-- | docs/boost.md | 149 | ||||
| -rw-r--r-- | docs/cmake.md | 113 | ||||
| -rw-r--r-- | project/boost/build.py | 15 | ||||
| -rw-r--r-- | project/boost/toolchain.py | 132 | ||||
| -rw-r--r-- | project/cmake/toolchain.py | 114 |
5 files changed, 264 insertions, 259 deletions
diff --git a/docs/boost.md b/docs/boost.md new file mode 100644 index 0000000..6e91d42 --- /dev/null +++ b/docs/boost.md @@ -0,0 +1,149 @@ +Library naming +-------------- + +The way Boost names library files by default is insane. It's absolutely not compatible between +OSs, compilers, Boost versions, etc. On Linux, for example, it would create +stage/lib/libboost_filesystem.a, while on Windows it would become something insane like +stage\lib\libboost_filesystem-vc142-mt-s-x64-1_72.lib. More than that, older Boost versions +wouldn't include architecture information (the "x64" part) in the file name, so you couldn't +store libraries for both x86 and x64 in the same directory. On Linux, on the other hand, you +can't even store debug/release binaries in the same directory. What's worse is that older CMake +versions don't support the architecture suffix, choking on the Windows example above. + +With all of that in mind, I decided to bring some uniformity by sacrificing some flexibility. +b2 is called with --layout=system, and libraries are put to stage/<platform>/<configuration>/lib, +where <platform> is x86/x64 and <configuration> is CMake's CMAKE_BUILD_TYPE. That means that I +can't have libraries with different runtime-link values in the same directory, but I don't really +care. + +Hate speech +----------- + +Is there a person who doesn't hate Boost.Build? I'm not sure, I'm definitely +_not_ one of these people. Maybe it's the lack of adoption (meaning that +learning it is useless outside of Boost), maybe it's the incomprehensible +syntax. Maybe it's the absolutely insane compiler-specific configuration +files (tools/build/src/tools/*.jam), which are impossible to figure out. +Maybe it's the fact that the implementation switched from C to C++ while some +half-baked Python implementation has been there since at least 2015 (see the +marvelous memo "Status: mostly ported." at the top of tools/build/src/build_system.py). + +What I hate the most though is how its various subtle, implicit and invisible +decision-making heuristics changed thoughout the release history of Boost. +You have a config and a compiler that will happily build version 1.65.0? +Great! Want to use the same config and the same compiler to build version +1.72.0? Well, too fucking bad, it doesn't work anymore. This I really do +hate the most. + +Three kinds of toolsets +----------------------- + +b2 accepts the toolset= parameter. What about building b2 itself though? +Well, this is what the bootstrap.{sh,bat} scripts do. They also accept a +toolset argument, but it is _completely_ different to that of b2. That's +sort of OK, since e.g. cross-compiling b2 is something we rarely want to do +(and hence there must typically be a native toolset available). + +bootstrap.sh and bootstrap.bat are completely different (of course!), and +accept different arguments for their toolset parameters. + +Config file insanity +-------------------- + +Say, we're building Boost on Windows using the GCC from a MinGW-w64 +distribution. We can pass toolset=gcc and all the required flags on the +command line no problem. What if we want to make a user configuration file +so that 1) the command line is less polluted, and 2) it can possibly be +shared? Well, if we put + + using gcc : : : <name>value... ; + +there, Boost 1.65.0 will happily build everything, while Boost 1.72.0 will +complain about "duplicate initialization of gcc". This is because when we +ran `bootstrap.bat gcc` earlier, it wrote `using gcc ;` in project-config.jam. +And while Boost 1.65.0 detects that toolset=gcc means we're going to use the +MinGW GCC, and magically turns toolset=gcc to toolset=gcc-mingw, Boost 1.72.0 +does no such thing, and chokes on the "duplicate" GCC declaration. + +We also cannot put + + using gcc : custom : : <options> ; + +without the executable path, since Boost insists that `g++ -dumpversion` must +equal to "custom" (which makes total sense, lol). So we have to force it, +and do provide the path. + +Windows & Clang +--------------- + +Building Boost using Clang on Windows is a sad story. As of 2020, there're +three main ways to install the native Clang toolchain on Windows: + + * download the installer from llvm.org (`choco install llvm` does this) + a.k.a. the upstream, + * install it as part of a MSYS2 installation (`pacman -S mingw-w64-x86_64-clang`), + * install as part of a Visual Studio installation. + +Using the latter method, you can switch a project to use the LLVM toolset +using Visual Studio, but that's stupid. The former two, on the other hand, +give us the the required clang/clang++/clang-cl executables, so everything +seems to be fine. + +Except it's not fine. Let's start with the fact that prior to 1.66.0, +toolset=clang is completely broken on Windows. It's just an alias for +clang-linux, and it's hardcoded to require the ar & ranlib executables to +create static libraries. Which is fine on Linux, since, and I'm quoting the +source, "ar is always available". But it's not fine on Windows, since +ar/ranlib are not, in fact, available there by default. Sure, you can +install some kind of MinGW toolchain, and it might even work, but what the +hell, honestly? + +Luckily, both the upstream distribution and the MSYS2 mingw-w64-x86_64-llvm +package come with the llvm-ar and llvm-ranlib utilities. So we can put +something like this in the config: + + using clang : custom : clang++.exe : <archiver>llvm-ar <ranlib>llvm-ranlib.exe ; + +and later call + + b2 toolset=clang-custom --user-config=path/to/config.jam ... + +But, as I mentioned, prior to 1.66.0, toolset=clang is _hardcoded_ to use ar +& ranlib, these exact utility names. So either get them as part of some +MinGW distribution or build Boost using another toolset. + +Now, it's all fine, but building stuff on Windows adds another thing into the +equation: debug runtimes. When you build Boost using MSVC, for example, it +picks one of the appropriate /MT[d] or /MD[d] flags to build the Boost +libraries with. Emulating these flags with toolset=clang is complicated and +inconvenient. Luckily, there's the clang-cl.exe executable, which aims to +provide command line interface compatible with that of cl.exe. + +Boost.Build even supports toolset=clang-win, which should use clang-cl.exe. +But alas, it's completely broken prior to 1.69.0. It just doesn't work at +all. So, if you want to build w/ clang-cl.exe, either use Boost 1.69.0 or +later, or build using another toolset. + +Cygwin & Clang +-------------- + +Now, a few words about Clang on Cygwin. When building 1.65.0, I encountered +the following error: + + /usr/include/w32api/synchapi.h:127:26: error: conflicting types for 'Sleep' + WINBASEAPI VOID WINAPI Sleep (DWORD dwMilliseconds); + ^ + ./boost/smart_ptr/detail/yield_k.hpp:64:29: note: previous declaration is here + extern "C" void __stdcall Sleep( unsigned long ms ); + ^ + +GCC doesn't emit an error here because /usr/include is in a pre-configured +"system" include directories list, and the declaration there take precedence, +I guess? The root of the problem BTW is that sizeof(unsigned long) is + + * 4 for MSVC and MinGW-born GCCs, + * 8 for Clang (and, strangely, Cygwin GCC; why don't we get runtime + errors?). + +The fix is to add `define=BOOST_USE_WINDOWS_H`. I don't even know what's the +point of not having it as a default. diff --git a/docs/cmake.md b/docs/cmake.md new file mode 100644 index 0000000..17a1d34 --- /dev/null +++ b/docs/cmake.md @@ -0,0 +1,113 @@ +Default generator +----------------- + +As of CMake 3.18, the default generator (unless set explicitly) is: + * the newest Visual Studio or "NMake Makefiles" on Windows, + * "Unix Makefiles" otherwise. +This is regardless of whether any executables like gcc, cl or make are +available [1]. + +Makefile generators +------------------- + +CMake has a number of "... Makefiles" generators. "Unix Makefiles" uses +gmake/make/smake, whichever is found first, and cc/c++ for compiler +detection [2]. "MinGW Makefiles" looks for mingw32-make.exe in a number of +well-known locations, uses gcc/g++ directly, and is aware of windres [3]. In +addition, "Unix Makefiles" uses /bin/sh as the SHELL value in the Makefile, +while the MinGW version uses cmd.exe. I don't think it matters on Windows +though, since the non-existent /bin/sh is ignored anyway [4]. "NMake +Makefiles" is similar, except it defaults to using cl [5]. + +It's important to _not_ use the -A parameter with any of the Makefile +generators - it's an error. This goes for "NMake Makefiles" also. "NMake +Makefiles" doesn't attempt to search for installed Visual Studio compilers, +you need to use it from one of the Visual Studio-provided shells. + +Visual Studio generators +------------------------ + +These are special. They ignore the CMAKE_<LANG>_COMPILER parameters and use +cl by default [9]. They support specifying the toolset to use via the -T +parameter (the "Platform Toolset" value in the project's properties) since +3.18 [10]. The toolset list varies between Visual Studio versions, and I'm +too lazy to learn exactly which version supports which toolsets. + +cmake --build uses msbuild with Visual Studio generators. You can pass the +path to a different cl.exe by doing something like + + msbuild ... /p:CLToolExe=another-cl.exe /p:CLToolPath=C:\parent\dir + +It's important that the generators for Visual Studio 2017 or older use Win32 +Win32 as the default platform [12]. Because of that, we need to pass the -A +parameter. + +mingw32-make vs make +-------------------- + +No idea what the actual differences are. The explanation in the FAQ [6] +about how GNU make "is lacking in some functionality and has modified +functionality due to the lack of POSIX on Win32" isn't terribly helpful. + +It's important that you can install either on Windows (`choco install make` +for GNU make and `choco install mingw` to install a MinGW-w64 distribution +with mingw32-make.exe included). Personally, I don't see any difference +between using either make.exe or mingw32-make.exe w/ CMake on Windows. But, +since MinGW-w64 distributions do include mingw32-make.exe and not make.exe, +we'll try to detect that. + +Cross-compilation +----------------- + +If you want to e.g. build x86 binary on x64 and vice versa, the easiest way +seems to be to make a CMake "toolchain file", which initializes the proper +compiler flags (like -m64/-m32, etc.). Such file could look like this: + + set(CMAKE_C_COMPILER gcc) + set(CMAKE_C_FLAGS -m32) + set(CMAKE_CXX_COMPILER g++) + set(CMAKE_CXX_FLAGS -m32) + +You can then pass the path to it using the CMAKE_TOOLCHAIN_FILE parameter. + +If you use the Visual Studio generators, just use the -A parameter, like "-A +Win32". + +As a side note, if you want to cross-compile between x86 and x64 using GCC on +Ubuntu, you need to install the gcc-multilib package. + +Windows & Clang +--------------- + +Using Clang on Windows is no easy task, of course. Prior to 3.15, there was +no support for building things using the clang++.exe executable, only +clang-cl.exe was supported [7]. If you specified -DCMAKE_CXX_COMPILER=clang++, +CMake would stil pass MSVC-style command line options to the compiler (like +/MD, /nologo, etc.), which clang++ doesn't like [8]. + +So, in summary, you can only use clang++ since 3.15. clang-cl doesn't work +with Visual Studio generators unless you specify the proper toolset using the +-T parameter. You can set the ClToolExe property using msbuild, but while +that might work in practice, clang-cl.exe needs to map some unsupported +options for everything to work properly. For an example of how this is done, +see the LLVM.Cpp.Common.* files at [11]. + +I recommend using Clang (either clang-cl or clang++ since 3.15) using the +"NMake Makefiles" generator. + +References +---------- + +[1]: cmake::EvaluateDefaultGlobalGenerator + https://github.com/Kitware/CMake/blob/v3.18.4/Source/cmake.cxx +[2]: https://github.com/Kitware/CMake/blob/v3.18.4/Source/cmGlobalUnixMakefileGenerator3.cxx +[3]: https://github.com/Kitware/CMake/blob/v3.18.4/Source/cmGlobalMinGWMakefileGenerator.cxx +[4]: https://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html +[5]: https://github.com/Kitware/CMake/blob/v3.18.4/Source/cmGlobalNMakeMakefileGenerator.cxx +[6]: http://mingw.org/wiki/FAQ +[7]: https://cmake.org/cmake/help/v3.15/release/3.15.html#compilers +[8]: https://github.com/Kitware/CMake/blob/v3.14.7/Modules/Platform/Windows-Clang.cmake +[9]: https://gitlab.kitware.com/cmake/cmake/-/issues/19174 +[10]: https://cmake.org/cmake/help/v3.8/release/3.8.html +[11]: https://github.com/llvm/llvm-project/tree/e408935bb5339e20035d84307c666fbdd15e99e0/llvm/tools/msbuild +[12]: https://cmake.org/cmake/help/v3.18/generator/Visual%20Studio%2015%202017.html diff --git a/project/boost/build.py b/project/boost/build.py index 3a073f3..612d815 100644 --- a/project/boost/build.py +++ b/project/boost/build.py @@ -23,21 +23,6 @@ By default, only builds: * statically linked to the runtime. ''' -# The way Boost names library files by default is insane. It's absolutely not compatible between -# OSs, compilers, Boost versions, etc. On Linux, for example, it would create -# stage/lib/libboost_filesystem.a, while on Windows it would become something insane like -# stage\lib\libboost_filesystem-vc142-mt-s-x64-1_72.lib. More than that, older Boost versions -# wouldn't include architecture information (the "x64" part) in the file name, so you couldn't -# store libraries for both x86 and x64 in the same directory. On Linux, on the other hand, you -# can't even store debug/release binaries in the same directory. What's worse is that older CMake -# versions don't support the architecture suffix, choking on the Windows example above. -# -# With all of that in mind, I decided to bring some uniformity by sacrificing some flexibility. -# b2 is called with --layout=system, and libraries are put to stage/<platform>/<configuration>/lib, -# where <platform> is x86/x64 and <configuration> is CMake's CMAKE_BUILD_TYPE. That means that I -# can't have libraries with different runtime-link values in the same directory, but I don't really -# care. - import argparse from contextlib import contextmanager import logging diff --git a/project/boost/toolchain.py b/project/boost/toolchain.py index 37f24ea..08bc49c 100644 --- a/project/boost/toolchain.py +++ b/project/boost/toolchain.py @@ -3,137 +3,7 @@ # For details, see https://github.com/egor-tensin/cmake-common. # Distributed under the MIT License. -# Hate speech -# ----------- -# -# Is there a person who doesn't hate Boost.Build? I'm not sure, I'm definitely -# _not_ one of these people. Maybe it's the lack of adoption (meaning that -# learning it is useless outside of Boost), maybe it's the incomprehensible -# syntax. Maybe it's the absolutely insane compiler-specific configuration -# files (tools/build/src/tools/*.jam), which are impossible to figure out. -# Maybe it's the fact that the implementation switched from C to C++ while some -# half-baked Python implementation has been there since at least 2015 (see the -# marvelous memo "Status: mostly ported." at the top of tools/build/src/build_system.py). -# -# What I hate the most though is how its various subtle, implicit and invisible -# decision-making heuristics changed thoughout the release history of Boost. -# You have a config and a compiler that will happily build version 1.65.0? -# Great! Want to use the same config and the same compiler to build version -# 1.72.0? Well, too fucking bad, it doesn't work anymore. This I really do -# hate the most. -# -# Three kinds of toolsets -# ----------------------- -# -# b2 accepts the toolset= parameter. What about building b2 itself though? -# Well, this is what the bootstrap.{sh,bat} scripts do. They also accept a -# toolset argument, but it is _completely_ different to that of b2. That's -# sort of OK, since e.g. cross-compiling b2 is something we rarely want to do -# (and hence there must typically be a native toolset available). -# -# bootstrap.sh and bootstrap.bat are completely different (of course!), and -# accept different arguments for their toolset parameters. -# -# Config file insanity -# -------------------- -# -# Say, we're building Boost on Windows using the GCC from a MinGW-w64 -# distribution. We can pass toolset=gcc and all the required flags on the -# command line no problem. What if we want to make a user configuration file -# so that 1) the command line is less polluted, and 2) it can possibly be -# shared? Well, if we put -# -# using gcc : : : <name>value... ; -# -# there, Boost 1.65.0 will happily build everything, while Boost 1.72.0 will -# complain about "duplicate initialization of gcc". This is because when we -# ran `bootstrap.bat gcc` earlier, it wrote `using gcc ;` in project-config.jam. -# And while Boost 1.65.0 detects that toolset=gcc means we're going to use the -# MinGW GCC, and magically turns toolset=gcc to toolset=gcc-mingw, Boost 1.72.0 -# does no such thing, and chokes on the "duplicate" GCC declaration. -# -# We also cannot put -# -# using gcc : custom : : <options> ; -# -# without the executable path, since Boost insists that `g++ -dumpversion` must -# equal to "custom" (which makes total sense, lol). So we have to force it, -# and do provide the path. -# -# Windows & Clang -# --------------- -# -# Building Boost using Clang on Windows is a sad story. As of 2020, there're -# three main ways to install the native Clang toolchain on Windows: -# -# * download the installer from llvm.org (`choco install llvm` does this) -# a.k.a. the upstream, -# * install it as part of a MSYS2 installation (`pacman -S mingw-w64-x86_64-clang`), -# * install as part of a Visual Studio installation. -# -# Using the latter method, you can switch a project to use the LLVM toolset -# using Visual Studio, but that's stupid. The former two, on the other hand, -# give us the the required clang/clang++/clang-cl executables, so everything -# seems to be fine. -# -# Except it's not fine. Let's start with the fact that prior to 1.66.0, -# toolset=clang is completely broken on Windows. It's just an alias for -# clang-linux, and it's hardcoded to require the ar & ranlib executables to -# create static libraries. Which is fine on Linux, since, and I'm quoting the -# source, "ar is always available". But it's not fine on Windows, since -# ar/ranlib are not, in fact, available there by default. Sure, you can -# install some kind of MinGW toolchain, and it might even work, but what the -# hell, honestly? -# -# Luckily, both the upstream distribution and the MSYS2 mingw-w64-x86_64-llvm -# package come with the llvm-ar and llvm-ranlib utilities. So we can put -# something like this in the config: -# -# using clang : custom : clang++.exe : <archiver>llvm-ar <ranlib>llvm-ranlib.exe ; -# -# and later call -# -# b2 toolset=clang-custom --user-config=path/to/config.jam ... -# -# But, as I mentioned, prior to 1.66.0, toolset=clang is _hardcoded_ to use ar -# & ranlib, these exact utility names. So either get them as part of some -# MinGW distribution or build Boost using another toolset. -# -# Now, it's all fine, but building stuff on Windows adds another thing into the -# equation: debug runtimes. When you build Boost using MSVC, for example, it -# picks one of the appropriate /MT[d] or /MD[d] flags to build the Boost -# libraries with. Emulating these flags with toolset=clang is complicated and -# inconvenient. Luckily, there's the clang-cl.exe executable, which aims to -# provide command line interface compatible with that of cl.exe. -# -# Boost.Build even supports toolset=clang-win, which should use clang-cl.exe. -# But alas, it's completely broken prior to 1.69.0. It just doesn't work at -# all. So, if you want to build w/ clang-cl.exe, either use Boost 1.69.0 or -# later, or build using another toolset. -# -# Cygwin & Clang -# -------------- -# -# Now, a few words about Clang on Cygwin. When building 1.65.0, I encountered -# the following error: -# -# /usr/include/w32api/synchapi.h:127:26: error: conflicting types for 'Sleep' -# WINBASEAPI VOID WINAPI Sleep (DWORD dwMilliseconds); -# ^ -# ./boost/smart_ptr/detail/yield_k.hpp:64:29: note: previous declaration is here -# extern "C" void __stdcall Sleep( unsigned long ms ); -# ^ -# -# GCC doesn't emit an error here because /usr/include is in a pre-configured -# "system" include directories list, and the declaration there take precedence, -# I guess? The root of the problem BTW is that sizeof(unsigned long) is -# -# * 4 for MSVC and MinGW-born GCCs, -# * 8 for Clang (and, strangely, Cygwin GCC; why don't we get runtime -# errors?). -# -# The fix is to add `define=BOOST_USE_WINDOWS_H`. I don't even know what's the -# point of not having it as a default. +# See docs/boost.md for a more thorough description of my pain. import abc from contextlib import contextmanager diff --git a/project/cmake/toolchain.py b/project/cmake/toolchain.py index c2e54a6..14197aa 100644 --- a/project/cmake/toolchain.py +++ b/project/cmake/toolchain.py @@ -3,119 +3,7 @@ # For details, see https://github.com/egor-tensin/cmake-common. # Distributed under the MIT License. -# Default generator -# ----------------- -# -# As of CMake 3.18, the default generator (unless set explicitly) is: -# * the newest Visual Studio or "NMake Makefiles" on Windows, -# * "Unix Makefiles" otherwise. -# This is regardless of whether any executables like gcc, cl or make are -# available [1]. -# -# Makefile generators -# ------------------- -# -# CMake has a number of "... Makefiles" generators. "Unix Makefiles" uses -# gmake/make/smake, whichever is found first, and cc/c++ for compiler -# detection [2]. "MinGW Makefiles" looks for mingw32-make.exe in a number of -# well-known locations, uses gcc/g++ directly, and is aware of windres [3]. In -# addition, "Unix Makefiles" uses /bin/sh as the SHELL value in the Makefile, -# while the MinGW version uses cmd.exe. I don't think it matters on Windows -# though, since the non-existent /bin/sh is ignored anyway [4]. "NMake -# Makefiles" is similar, except it defaults to using cl [5]. -# -# It's important to _not_ use the -A parameter with any of the Makefile -# generators - it's an error. This goes for "NMake Makefiles" also. "NMake -# Makefiles" doesn't attempt to search for installed Visual Studio compilers, -# you need to use it from one of the Visual Studio-provided shells. -# -# Visual Studio generators -# ------------------------ -# -# These are special. They ignore the CMAKE_<LANG>_COMPILER parameters and use -# cl by default [9]. They support specifying the toolset to use via the -T -# parameter (the "Platform Toolset" value in the project's properties) since -# 3.18 [10]. The toolset list varies between Visual Studio versions, and I'm -# too lazy to learn exactly which version supports which toolsets. -# -# cmake --build uses msbuild with Visual Studio generators. You can pass the -# path to a different cl.exe by doing something like -# -# msbuild ... /p:CLToolExe=another-cl.exe /p:CLToolPath=C:\parent\dir -# -# It's important that the generators for Visual Studio 2017 or older use Win32 -# Win32 as the default platform [12]. Because of that, we need to pass the -A -# parameter. -# -# mingw32-make vs make -# -------------------- -# -# No idea what the actual differences are. The explanation in the FAQ [6] -# about how GNU make "is lacking in some functionality and has modified -# functionality due to the lack of POSIX on Win32" isn't terribly helpful. -# -# It's important that you can install either on Windows (`choco install make` -# for GNU make and `choco install mingw` to install a MinGW-w64 distribution -# with mingw32-make.exe included). Personally, I don't see any difference -# between using either make.exe or mingw32-make.exe w/ CMake on Windows. But, -# since MinGW-w64 distributions do include mingw32-make.exe and not make.exe, -# we'll try to detect that. -# -# Cross-compilation -# ----------------- -# -# If you want to e.g. build x86 binary on x64 and vice versa, the easiest way -# seems to be to make a CMake "toolchain file", which initializes the proper -# compiler flags (like -m64/-m32, etc.). Such file could look like this: -# -# set(CMAKE_C_COMPILER gcc) -# set(CMAKE_C_FLAGS -m32) -# set(CMAKE_CXX_COMPILER g++) -# set(CMAKE_CXX_FLAGS -m32) -# -# You can then pass the path to it using the CMAKE_TOOLCHAIN_FILE parameter. -# -# If you use the Visual Studio generators, just use the -A parameter, like "-A -# Win32". -# -# As a side note, if you want to cross-compile between x86 and x64 using GCC on -# Ubuntu, you need to install the gcc-multilib package. -# -# Windows & Clang -# --------------- -# -# Using Clang on Windows is no easy task, of course. Prior to 3.15, there was -# no support for building things using the clang++.exe executable, only -# clang-cl.exe was supported [7]. If you specified -DCMAKE_CXX_COMPILER=clang++, -# CMake would stil pass MSVC-style command line options to the compiler (like -# /MD, /nologo, etc.), which clang++ doesn't like [8]. -# -# So, in summary, you can only use clang++ since 3.15. clang-cl doesn't work -# with Visual Studio generators unless you specify the proper toolset using the -# -T parameter. You can set the ClToolExe property using msbuild, but while -# that might work in practice, clang-cl.exe needs to map some unsupported -# options for everything to work properly. For an example of how this is done, -# see the LLVM.Cpp.Common.* files at [11]. -# -# I recommend using Clang (either clang-cl or clang++ since 3.15) using the -# "NMake Makefiles" generator. -# -# References -# ---------- -# -# [1]: cmake::EvaluateDefaultGlobalGenerator -# https://github.com/Kitware/CMake/blob/v3.18.4/Source/cmake.cxx -# [2]: https://github.com/Kitware/CMake/blob/v3.18.4/Source/cmGlobalUnixMakefileGenerator3.cxx -# [3]: https://github.com/Kitware/CMake/blob/v3.18.4/Source/cmGlobalMinGWMakefileGenerator.cxx -# [4]: https://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html -# [5]: https://github.com/Kitware/CMake/blob/v3.18.4/Source/cmGlobalNMakeMakefileGenerator.cxx -# [6]: http://mingw.org/wiki/FAQ -# [7]: https://cmake.org/cmake/help/v3.15/release/3.15.html#compilers -# [8]: https://github.com/Kitware/CMake/blob/v3.14.7/Modules/Platform/Windows-Clang.cmake -# [9]: https://gitlab.kitware.com/cmake/cmake/-/issues/19174 -# [10]: https://cmake.org/cmake/help/v3.8/release/3.8.html -# [11]: https://github.com/llvm/llvm-project/tree/e408935bb5339e20035d84307c666fbdd15e99e0/llvm/tools/msbuild -# [12]: https://cmake.org/cmake/help/v3.18/generator/Visual%20Studio%2015%202017.html +# See docs/cmake.md for a more thorough description of my pain. import abc import os.path |