Re: Adding CMakeLists.txt files

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2021-05-31 19:12:20

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.