While we already support `VERBOSE` environment variable and
`CMAKE_VERBOSE_MAKEFILE` cached variable, add `-v` and `--verbose`
command line options to be able to activate verbose output directly from
CMake's build tool mode command line.
Also make `msbuild` honor the verbosity setting. `xcodebuild` still
doesn't honor the verbosity setting as it will need a policy added
and reworking of cmGlobalGenerator and cmsys to support
multiple command invocation.
Temporarily restore previous behavior that allowed specifying
no source or build directory to work, even though it was
neither documented nor supported. This commit is expected
to eventually be reverted to restore the fatal error for such
cases.
Relates: #18817
67bced8a26 cmake-gui: Improve label for default platform
48ec0bc140 cmake-gui: Add field for generator platform selection
8bba458ea5 Add global generator factory method to get default platform name
818df52c48 Add global generator factory method to get list of known platforms
8144b00e32 Split global generator factory list with and without platforms
b70c0aed5c VS: Factor out helper function to compute host platform name
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2832
Required extracting default generator evaluation
to explicit function, as Visual Studio generators
get validated during their construction.
Fixes: #18544
The GetGeneratorDocumentation() function was not accurately
named and required the vector to populate to be passed as a
function argument. This commit makes the slightly renamed
function return by value, making it a true getter as implied
by its name. Some minor refactoring of the implementation
also makes the steps of populating the vector clearer.
Add a `cmGlobalGeneratorFactory::GetKnownPlatforms` method to return
a list of known possible values for `CMAKE_GENERATOR_PLATFORM`.
Implement the method for each generator by referencing the list of
possible values documented in `Help/generator/*.rst` for it.
Co-Author: Julien Jomier <julien.jomier@kitware.com>
Replace `cmGlobalGeneratorFactory::GetGenerators` with a pair of methods
to split the list of generator names into those that have platforms in
the name and those that do not.
57e48f16f2 VS: Add Visual Studio 16 2019 generator
bdef729646 VS: Parameterize VS 2017 generator to support future versions
68d316e0cf VS: Rename VS 2017 generator sources to be version-independent
d8ed309d05 VS: Parameterize cmVSSetupAPIHelper instances with VS version
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2789
27eb7c5bdb cmake: Ensure source and binary dirs are set
a1adbc7243 cmake: Stop processing if -P option lacks file name
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2799
If only the source dir is provided, the binary dir is assumed
to be the working directory. If only the binary dir is provided
and it doesn't yet have a CMakeCache.txt to provide the
source dir, then the source dir is assumed to be the working
directory. This logic was not previously being handled
correctly when -S and/or -B options were involved.
Furthermore, when both were missing, no suitable error
message was provided and an empty string was used for
the build directory.
Fixes: #18707
Add this generator *without* support for specifying the target
architecture in the generator name. cmake-gui will be taught
to provide a field for this, and command-line builds can use -A.
Also, teach this generator to select a default target architecture
based on the host architecture.
Fixes: #18689
Inspired-by: Egor Pugin <egor.pugin@gmail.com>
This results in the correct source directory being picked up in calls
with
cmake sourcedir -C settings
and in a more appropriate error message when calling
mkdir build ; cd build ; cmake -C settings
Also fix `-D` and `-U` in the same way.
In `cmake::CreateDefaultGlobalGenerator` the table of registry entries
does not need an entry for VS 2017 because that is found via the VS
setup helper.
Add a file-based API that clients may use to get semantic information
about the buildsystem that CMake generates. Clients will write query
files under a designated location in the build tree, and CMake will
write reply files for clients to read.
Start with support for shared stateless query files. These allow
clients to share requests for major object versions and get all those
recognized by CMake. Once any client has written a shared request to a
build tree it will persist. Other clients will not need to overwrite
the request (since it is stateless) and should not remove it either.
For now we add only an undocumented object kind to use for testing the
query and reply infrastructure. Object kinds providing real semantic
information will be added later.
Issue: #18398
