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
This commit continues the changes made in CTest to support std::chrono
by
applying it throughout every component where a duration was used.
No functional change intended.
This reintroduces the change from commit v3.10.0-rc1~69^2 (Performance:
Improve efficiency of source file lookup in cmMakefile, 2017-08-17) with
some corrections. The original was rolled back by commit
v3.10.0-rc1~52^2~1 (Revert "Performance: ...", 2017-09-25) due to
incompatibilities found. The rollback was followed-up by addition of a
test for the offending case, and this revision passes the test.
std::{begin,end} are part of C++11, std::{cbegin,cend} are part of C++14
and an standard compliant implementation has been introduced within the
'cm' namespace: cm::{cbegin,cend}.
std::size is only part of C++17, hence exposing a compliant implementation
within namespace cm (cm::size).
where possible, the standard implementations are reused.
Add cache entry `CMAKE_GENERATOR_INSTANCE` to hold the instance location
persistently across re-runs of CMake in a given build tree.
For now we reject the option by default if explicitly set. It will be
implemented on a per-generator basis. Pass the setting into try_compile
project generation. Add a RunCMake.GeneratorInstance test to cover
basic use cases for the option. Verify that `CMAKE_GENERATOR_INSTANCE`
is empty by default, and that it is rejected when the generator does not
support a user setting.
Issue: #17268
We don't need to save the `CMAKE_GENERATOR_{PLATFORM,TOOLSET}` values
from the cache back into the `cmake` instance. They were used only to
propagate the settings into `cmake` instances for `try_compile`, but we
already have their values in the `cmMakefile`'s variables anyway. In
fact those variables are the ones we actually give to the generators.
These functions just need to change the directory for a block of code
and then go back to the caller's expected location. Use
cmWorkingDirectory to ensure that all return paths are handled.
VS 2017 and later may no longer populate the Windows Registry entries
CMake has traditionally used to find the VS installations. This is
because VS now supports having multiple installations of the same
version. The Visual Studio Installer tool provides a COM interface we
can query to locate installations.
Visual Studio's build system does not cleanly handle itself being
re-generated during the build. Teach `cmake --build` to check whether
the build system needs to be re-generated before launching the native
build tool.
Some versions of the VS tools do not install the registry entry
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\$v;InstallDir
but all appear to set
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\$v\Setup\VC;ProductDir
Update our search to consider both entries.
Closes: #16360
Refactoring in commit v3.7.0-rc1~291^2~1 (Refactor extra generator
registration to use factories, 2016-07-20) accidentally switched
the order of the "extra - base" generator names to "base - extra".
Switch it back. While this could affect all callers of the
`GetRegisteredGenerators` method, only cmake-gui actually used this
particular field.
Closes: #16359
Add a cmOutputConverter to the cmLinkLineComputer and factory methods to
facilitate shell escapes.
Add state to the cmLinkLineComputer to record whether outputting for
response files or for watcom, to satisfy the cmOutputConverter API.
These are constant for the lifetime of the cmLinkLineComputer, even when
its functionality is extended in the future. This also keeps the
signatures of cmLinkLineComputer relatively simple.
Pass the cmComputeLinkInformation as a method parameter so that
cmLinkLineComputer is free from target-specific state. An instance
should be usable for all targets in a directory.
CMake has several classes which have too many responsibilities.
cmLocalGenerator is one of them. Start to extract the link line
computation. Create generator-specific implementations of the interface
to account for generator-specific behavior.
Unfortunately MSVC60 has different behavior to everything else and CMake
still generates makefiles for it. Isolate it with MSVC60-specific
names.
Per-source copyright/license notice headers that spell out copyright holder
names and years are hard to maintain and often out-of-date or plain wrong.
Precise contributor information is already maintained automatically by the
version control tool. Ultimately it is the receiver of a file who is
responsible for determining its licensing status, and per-source notices are
merely a convenience. Therefore it is simpler and more accurate for
each source to have a generic notice of the license name and references to
more detailed information on copyright holders and full license terms.
Our `Copyright.txt` file now contains a list of Contributors whose names
appeared source-level copyright notices. It also references version control
history for more precise information. Therefore we no longer need to spell
out the list of Contributors in each source file notice.
Replace CMake per-source copyright/license notice headers with a short
description of the license and links to `Copyright.txt` and online information
available from "https://cmake.org/licensing". The online URL also handles
cases of modules being copied out of our source into other projects, so we
can drop our notices about replacing links with full license text.
Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority
of the replacements mechanically. Manually fix up shebang lines and trailing
newlines in a few files. Manually update the notices in a few files that the
script does not handle.
Refactoring in commit v2.8.10~58^2~2 (Ninja: move -LIBPATH behind -link
option, 2012-09-26) added arguments to cmLocalGenerator::GetTargetFlags
and updated the call sites. However, in the cmake::FindPackage and
cmLocalGenerator::AddBuildTargetRule call sites it added the new
arguments in the wrong order. The latter was never used and has been
removed. The former remains buggy and prints out compiler flags instead
of the link framework/library search paths. Fix its argument order.
Introduce cmake::ReportCapabilitiesJson which returns a the Json object
that is serialized in cmake::ReportCapabilities.
This allows to re-use the information in cmake-server.
Alex Neundorf