239a3ef8 Server-mode: Document protocol version for optional handshake arguments
9b1a3d24 Server-mode: Rename functions to reflect what they do
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1693
Document which Protocol version only needs the build directory to be passed
during a handshake.
This is available a bit earlier than that, but from all I can tell 1.2 is
the earliest version where that feature is reliably available.
The last KDevelop3 release was many years ago, in 2008 I think.
I haven't seen or read about anybody using KDevelop 3 since a
long time, so I think it can safely be removed from CMake.
KDevelop 4 (first released in 2010) has its own proper CMake
support now, independent from this generator.
Alex
The set of compile flags used for a target's C and C++ sources is based
on the linker language. By default this is always the C++ flags if any
C++ sources appear in the target, and otherwise the C flags. Therefore
we can define the `COMPILE_LANGUAGE` generator expression in
`INCLUDE_DIRECTORIES` to match the selected language.
This is not exactly the same as for other generators, but is the best VS
and Xcode can do. It is also sufficient for many use cases since the
set of include directories for C and C++ is frequently similar but may
be distinct from those for other languages like CUDA.
Fixes: #17435
The set of compile flags used for a target's C and C++ sources is based
on the linker language. By default this is always the C++ flags if any
C++ sources appear in the target, and otherwise the C flags. Therefore
we can define the `COMPILE_LANGUAGE` generator expression in
`COMPILE_DEFINITIONS` to match the selected language.
This is not exactly the same as for other generators, but is the best VS
and Xcode can do. It is also sufficient for many use cases since the
set of definitions for C and C++ is frequently similar but may be
distinct from those for other languages like CUDA.
Issue: #17435
This removes duplicated code for per-config variable initialization by
providing a `cmake_initialize_per_config_variable(<PREFIX> <DOCSTRING>)`
function.
This function initializes a `<PREFIX>` cache variable from `<PREFIX>_INIT`
and unless the `CMAKE_NOT_USING_CONFIG_FLAGS` variable is defined, does
the same with `<PREFIX>_<CONFIG>` from `<PREFIX>_<CONFIG>_INIT` for every
`<CONFIG>` in `CMAKE_CONFIGURATION_TYPES` for multi-config generators or
`CMAKE_BUILD_TYPE` for single-config generators.
Backtrace information was included by commit 35a52bd1b4 (server: add
"ctestInfo" request to get test info, 2017-10-25) to match that already
provided for targets. However, the backtrace representation uses too
much memory and needs to be dropped. Remove it from test information.
Issue: #17502
The backtrace information is very repetitive and hugely increases the
size of the codemodel object. We need to remove it until an alternative
representation can be developed. Revert commit v3.10.0-rc1~393^2
(server: Report backtraces in codemodel response, 2017-06-20), except
for the protocol version number (because it indicates other new things).
Unfortunately this is incompatible with clients that expect the
"crossReferences" field in targets. However, the regression in memory
usage is quite serious, especially on large projects, and therefore
breaks even older clients that do not use backtraces. Since the
"crossReferences" field was only provided by one release (3.10.0), it is
simplest to revert it outright for 3.10.1.
Fixes: #17502
This enables configuration of build parallelism with the Ninja generator by
passing arguments on the command line to CMake. For example,
cmake \
'-DCMAKE_JOB_POOLS:STRING=compile=5;link=2' \
-DCMAKE_JOB_POOL_COMPILE:STRING=compile \
-DCMAKE_JOB_POOL_LINK:STRING=link \
~/src/MyProject
CodeBlocks uses his own compiler ID string which may differ from
CMAKE_<LANG>_COMPILER_ID. In particular CodeBlocks supports a large
number of different compiler configurations (with different IDs)
This commit adds a cache variable "CMAKE_CODEBLOCKS_COMPILER_ID",
so the user might adjust it when needed.
2ae880fa Genex: Enable COMPILE_LANGUAGE for COMPILE_OPTIONS with Visual Studio
2b7d59f3 Genex: Enable COMPILE_LANGUAGE for file(GENERATE) with Visual Studio
0f6f7c8a Genex: Fix COMPILE_LANGUAGE messages to allow file(GENERATE) with Xcode
c5a82d0f Tests: Decouple COMPILE_LANGUAGE in file(GENERATE) from COMPILE_OPTIONS
25773650 Tests: Remove unnecessary result files from RunCMake.File_Generate
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Jason Juang <jasjuang@gmail.com>
Merge-request: !1511
Some generators auto-generate targets. For example VS generators create
the ALL_BUILD target. Add the ability to mark targets as generator
provided and return that info through cmake-server codemodel.
Since commit v3.9.0-rc4~3^2~1 (VS: Fix target_compile_options for CUDA,
2017-06-21), the evaluation of `COMPILE_LANGUAGE` receives the proper
language. The set of compile flags used for a target's C and C++
sources is based on the linker language. By default this is always the
C++ flags if any C++ sources appear in the target, and otherwise the C
flags. Therefore we can define the `COMPILE_LANGUAGE` generator
expression in `COMPILE_OPTIONS` to match the selected language.
This is not exactly the same as for other generators, but is the best VS
can do. It is also sufficient for many use cases since the set of
allowed flags for C and C++ is almost the same in Visual Studio.
Furthermore, since the VS generator moves many of the flags to
declarative `.vcxproj` elements, it will automatically avoid passing
C++ flags for C sources.
Issue: #17435
Introduces CPACK_DEFAULT_DIRECTORY_INSTALL_PERMISSIONS
variable which adds support for functionality introduced
by CMAKE_DEFAULT_DIRECTORY_INSTALL_PERMISSIONS variable.
Fixes#17333
# Conflicts:
# Help/release/dev/cmake-default-dir-install-permissions.rst
Introduces CMAKE_DEFAULT_DIRECTORY_INSTALL_PERMISSIONS
variable which enables the user to specify the default
permissions for directory creation. This setting is then
used to auto set the permissions on directories which
are implicitly created by install() and file(INSTALL)
commands such as CMAKE_INSTALL_PREFIX directories.
The purpose of this new `IMPORTED_GLOBAL` target-property is to prolong
the lifetime and scope of `IMPORTED` targets in such a way as if they
had been created with the keyword `GLOBAL` in the first place.
* It can only be set to `TRUE`. That means, a local `IMPORTED` target
can be promoted to global scope but a global `IMPORTED` target cannot
be degraded to local scope!
* Setting it to `TRUE` only succeeds if done from within the same
directory in which the `IMPORTED` target was created in the first
place.
Fixes#17256.
