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
>>> 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
> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk