|
Boost : |
From: Edward Diener (eldiener_at_[hidden])
Date: 2021-05-31 18:26:11
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.
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.
>
> I do agree, however, that cmake documentation could largely be
> improved. Good news is that this is actually happening (documentation
> was far worse several years ago, and gets better with every release).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk