On 5/31/21 9:26 PM, Edward Diener via Boost wrote:
On 5/31/2021 12:15 PM, Julien Blanc via Boost wrote:
Le lundi 31 mai 2021 à 08:13 -0400, Edward Diener via Boost a écrit :
My beef is that the CMake documentation does not tell you what compilers a particular generator supports, except for the Visual Studio generators. Period.
Because this is an odd question, in a cmake-centric view. Any generator can launch any compiler (any build step) as part of the build process. They're orthogonal concepts. Now there is the special case of Visual Studio, where the build system, the project manager and the compiler are so tied together that it makes it really hard to use the VS build system to compile using any other compiler, and vice-versa. Which is why it is mentioned in the generator documentation.
If any generator can launch any compiler what is the point of choosing a generator ? Is it just that the end-user knows which generators exist on his system ? I would think that generators are just in artefact and you should only need to tell CMake that you want to use some command for compiler and perhaps an alternate command for linker and other tools you need and CMake would just choose a generator it can find on your system and go from there.
I think, there is a use case where the developer generates a Visual Studio or XCode project with CMake and opens and uses that project in his IDE to work on the project, including code editing, compiling, debugging, etc. I think, this kind of workflow was advertised in the early days of CMake as a feature - write one CMakeLists.txt, use that to work on your project from whatever your favorite IDE. I'm not sure how relevant it is today. This isn't as much of a feature when you have an IDE that can work with CMake natively, or when you generate something low level like a Makefile or a Ninja script. In this case, the generated files are pretty much the cached result of a configure step (as a somewhat close analogy, Boost.Build generates project-cache.jam). It's just in the form of generated Makefiles CMake also caches the tree of build targets, which Boost.Build has to generate every time you run it, which has a noticeable delay.
Programmers think in terms of 'what compiler and/or other tools do I need to build some software'. This whole business of generators is a CMake invention, which should have been merely a CMake internal detail. If CMake were truly what it no doubt wishes itself to be, it could simply take the tools you specify, find internally a generator which could use those tools, create its files, and then tell you to use CMake --build to build your project and CMake --test to test your project etc. etc. Instead the docs give you all this information about generators, no immediate information about how you specify the compiler and any other tools you need on the CMake command line, and expects that to satisfy everybody.
The CMake ability to build and test is a relatively recent addition. Originally, it really was a tool to generate a project for your favorite build system from a common description and nothing more. It really was *not* a build system, but a *meta build system*, if you like. So, the question you would ask was how to use CMake to generate your IDE project, and the tool selection was mostly deferred to the IDE, where possible. Of course, it didn't work so well in practice because the generated projects and Makefiles are so very different. Heck, even to just configure build configuration type (debug/release/etc.) one had to write two different branches in CMakeLists.txt - one for Makefile-style build systems and the other for VS-style projects. Recently, as CMake takes on more and more functionality of a build system, providing portable ways of interaction with the underlying build system (and therefore removing the need of interacting with it directly), providing more portable ways of configuring the build, and as more and more IDEs integrating with CMake using its API, the generator stuff is getting mostly legacy. I think, it is currently half way there, so the kludges that stem from the underlying build system are still visible to the user, but much of the work can be done through CMake interfaces exclusively.