Clang-Tidy writes the number of warnings, the number of suppressed
warnings, and instructions on how to suppress warnings to stderr. Since
each source file is checked individually, this repetitive information is
disturbing and should be suppressed.
The actual warning messages are written to stdout. Some IDEs (eg.
QtCreator) analyze only stderr for issues. Redirecting Clang-Tidy's
stdout to stderr makes sure the warnings are correctly displayed.
To avoid Race conditions with other processes writing to stdout/stderr compose
the whole message in a std::stringstream then submit the single complete message.
84946c73 Tests: QtAutogen: Same source name in different directories test
9c6fa684 Autogen: Generate qrc_NAME.cpp files in subdirectories
488ea8c7 Autogen: Generate not included moc files in subdirectories (#12873)
66caae45 Autogen: Check added for name collisions of generated qrc_NAME.cpp files
663d093d Autogen: Check added for name collisions of generated ui_NAME.h files
8295d437 Autogen: Check added for name collisions of generated moc files
d350308a Help: Improve AUTOMOC documentation layout
2263949b cmGlobalXCodeGenerator: do not pass char* to cmSystemTools::CollapseFullPath()
2b25ce30 make cmGlobalXCodeGenerator::XCodeEscapePath() take a std::string&
ffedf352 make cmGlobalXCodeGenerator::BuildObjectListOrString::Add() take a string&
6100bdff cmGlobalXCodeGenerator: directly call CreateString() with std::string
A qrc_NAME.cpp file generated from NAME.qrc in the directory
CMAKE_CURRENT_SOURCE_DIR/SUBDIR
will be generated in the directory
CMAKE_CURRENT_BINARY_DIR/TARGETNAME_automoc.dir/SUBDIR
Not included moc files generated from a source file in
CMAKE_CURRENT_SOURCE_DIR/SUBDIR
will be generated in the directory
CMAKE_CURRENT_BINARY_DIR/TARGETNAME_automoc.dir/SUBDIR/
Running the testsuite this function is entered more than 126,000 times. Reorder
the code flow so that a conversion from char* to std::string is only done when
the cache entry is a path one, which happens only ~50 times during the
testsuite.
840b830b Autogen: Qrc processing: Generate single map with final input / output names
bc4c7751 Autogen: Ui processing: Generate single map with final input / output names
47e60bc5 Autogen: Split out UI file generation code to dedicated method
cf679ea8 Autogen: Split out moc file generation code to dedicated method
3ea1d090 Autogen: Rename method GenerateQrc{ => Files}
8ced8bb9 Autogen: New logCommand method. It prints commands using std::cout.
95064a6d Autogen: Rename header extension Join method to JoinExts
7a73c404 Autogen: Use SystemTools string functions instead of rolling out own
0f96ef00 Remove unused cmake::IssueMessage overload
563bf9dd cmState: Remove unused entry point fields from snapshot data
7c36d206 cmListFileBacktrace: Refactor storage to provide efficient value semantics
1f6bd8a9 cmState: Avoid accumulating snapshot storage for backtraces
18b6676b cmState: Add Snapshot method to get bottom of call stack
2faa8b36 Add call stack to unused/uninitialized variable warnings
da07c506 cmLocalGenerator: Simplify IssueMessage implementation
cc7aed77 cmLocalGenerator: Use own IssueMessage method
c50285de cmOutputConverter: Assert construction with a valid snapshot
b6ed71b1 cmMakefile: Move cmMakefileCall to .cxx file
a559f0f6 cmWhileCommand: Simplify context construction
7503deb2 cmIfCommand: Simplify execution context construction
All callers now pass a full backtrace so we do not need the alternative
that takes a cmListFileContext directly. Drop this overload to remove
the code duplication.
Since commit v3.4.0-rc1~321^2~2 (Genex: Store a backtrace, not a pointer
to one, 2015-07-08) we treat cmListFileBacktrace instances as
lightweight values. This was true at the time only because the
backtrace information was kept in the cmState snapshot hierarchy.
However, that forced us to accumulate a lot of otherwise short-lived
snapshots just to have the backtrace fields available for reference by
cmListFileBacktrace instances. Recent refactoring made backtrace
instances independent of the snapshot hierarchy to avoid accumulating
short-lived snapshots. This came at the cost of making backtrace values
heavy again, leading to lots of string coying and slower execution.
Fix this by refactoring cmListFileBacktrace to provide value semantics
with efficient shared storage underneath. Teach cmMakefile to maintain
its call stack using an instance of cmListFileBacktrace. This approach
allows the current backtrace to be efficiently saved whenever it is
needed.
Also teach cmListFileBacktrace the notion of a file-level scope. This
is useful for messages about the whole file (e.g. during parsing) that
are not specific to any line within it. Push the CMakeLists.txt scope
for each directory and never pop it. This ensures that we always have
some context information and simplifies cmMakefile::IssueMessage.
Push/pop a file-level scope as each included file is processed. This
supersedes cmParseFileScope and improves diagnostic message context
information in a few places. Fix the corresponding test cases to expect
the improved output.
Changes during post-3.3/pre-3.4 development refactored storage of most
configure-time information, including variable bindings and function
scopes. All scopes (even short-lived) were kept persistently for
possible future debugging features, causing huge accumulated memory
usage. This was mostly addressed by commit v3.4.1~4^2 (cmState: Avoid
accumulating snapshot storage for short-lived scopes, 2015-11-24).
Since then we still keep short-lived scopes when they are needed for a
backtrace. This is because since commit v3.4.0-rc1~378^2
(cmListFileBacktrace: Implement in terms of cmState::Snapshot,
2015-05-29) backtraces have been lightweight objects that simply point
into the snapshot tree. While the intention of this approach was to
avoid duplicating the call stack file path strings, the cost turned out
to be holding on to the entire call stack worth of scope snapshots,
which is much worse.
Furthermore, since commit v3.4.0-rc2~1^2 (cmIfCommand: Issue CMP0054
warning with appropriate context, 2015-10-20) all conditions used in
`if()` commands hold a backtrace for use in diagnostic messages. Even
though the backtrace is short-lived it still causes the scope snapshot
to be kept. This means that code like
function(foo)
if(0)
endif()
endfunction()
foreach(i RANGE 1000000)
foo()
endforeach()
accumulates storage for the function call scope snapshots.
Fix this by partially reverting commit v3.4.0-rc1~378^2 and saving the
entire call stack during cmListFileBacktrace construction. This way
we can avoid keeping short-lived scope snapshot storage in all cases.
In commit v2.8.4~32^2~14 (Use cmake::IssueMessage for warnings,
2010-12-07) these warnings became formatted. It is more informative to
give the full call stack with such warnings. Also it is easier to
implement warnings with a full call stack because we do not have to
construct a custom backtrace with only the top.
This method was added by commit v3.4.0-rc1~424^2~6 (cmLocalGenerator:
Add IssueMessage method, 2015-06-13) in order to reduce callers'
dependency on cmMakefile. Currently the implementation of
cmLocalGenerator::IssueMessage is just a copy of the post-configure code
path in cmMakefile::IssueMessage. De-duplicate the implementation by
simply calling the cmMakefile copy for now. This will simplify upcoming
refactoring of backtraces. The dependency on cmMakefile can be removed
by future work once that is done.
Create a <LANG>_CLANG_TIDY target property (initialized by a
CMAKE_<LANG>_CLANG_TIDY variable) to specify a clang-tidy command line
to be run along with the compiler.
In the `try_compile` source file signature we propagate the caller's
value of `CMAKE_<LANG>_FLAGS` into the test project. Extend this to
propagate `CMAKE_<LANG>_FLAGS_<CONFIG>` too instead of always using the
default value in the test project. This will be useful, for example, to
allow the MSVC runtime library to be changed (e.g. `-MDd` => `-MTd`).
7731e44f Ninja: Honor CMAKE_NINJA_FORCE_RESPONSE_FILE for compile rules
f9644a2d cmGlobalNinjaGenerator: Clarify logic for forcing use of response files
24c9106b cmNinjaTargetGenerator: Factor out helper for forced response file check
The change in commit v3.5.0-rc1~198^2 (Ninja: Always re-run custom
commands that have symbolic dependencies, 2015-11-19) broke the
byproducts feature added by commit v3.2.0-rc1~340^2~2 (Add an option for
explicit BYPRODUCTS of custom commands, 2014-11-13) when SYMBOLIC
outputs also appear. This case occurs with AUTORCC-generated custom
targets because the output is SYMBOLIC (to always run) and the generated
file is a byproduct (for restat so dependents do not run unnecessarily).
The two use cases conflict because Ninja does not support per-output
restat. Favor restat whenever byproducts are present because it is
required for byproducts to work correctly. In use cases where we want
an always-run chain we simply will not be able to also use byproducts.
Fix logic introduced by commit v3.5.0-rc1~198^2 (Ninja: Always re-run
custom commands that have symbolic dependencies, 2015-11-19) to not
consider only the last output. We need to know if any output is
SYMBOLIC, so stop checking as soon as one is found.
Since commit v3.5.0-rc1~241^2~1 (cmFortranParser: Parse #line
directives, 2015-11-02) our Fortran dependency scanner parses `#line`
directives to extract the named files. However, some compilers produce
`#line` directives that name directories instead of files. Work around
such cases by verifying that the extracted path names a file and not a
directory.
c18d91ad Help: add release notes for topic 'ctest-run-submodule-sync'
7f560743 cmCTestGIT: run `git submodule sync` before updating submodules
06b310b5 cmCTestGIT: add an option to initialize submodules on update
56c1ea40 cmCTestGIT: fix git version references
Currently, CTest will not initialize any submodules within the already
checked out source tree. Add an option to do so. The use case for not
doing so is that some submodules may not be necessary for the current
test and keeping network usage down may be important.
Rename methods:
* `cmMakefile::Find{ => LocalNonAlias}Target`
* `cmLocalGenerator::Find{ => LocalNonAlias}GeneratorTarget`
These names clarify that they are for directory-local target names
and do not consider alias targets.
Refactoring in commit v3.5.0-rc1~272^2~11 (cmTarget: Implement ALIAS in
terms of name mapping, 2015-10-25) accidentally introduced logic that
assumes ALIAS targets always reference targets in their own directory.
Fix this and add a test case.
The configure-step fix is that `cmMakefile::FindTarget` should not consider
aliases. The purpose of this method is just to look up targets local to
a directory. Since ALIAS and normal targets share a namespace we know a
locally defined target will never collide with an ALIAS target anyway.
The method has 3 call sites, and this change is safe for all of them:
* `cmInstallCommand::HandleTargetsMode`: Rejects aliases before the call.
* `cmFLTKWrapUICommand::FinalPass`: Should never have considered aliases.
* `cmMakefile::FindTargetToUse`: Falls back to a global lookup anyway.
The generate-step fix is that `cmLocalGenerator::FindGeneratorTarget`
should not consider aliases. This method is the generate-step
equivalent to the above. The method has 2 call sites, and this change
is safe for both of them:
* `cmInstallTargetGenerator::Compute`: Never uses an alias target name.
* `cmLocalGenerator::FindGeneratorTargetToUse`: Falls back to global lookup.
Reported-by: Matteo Settenvini <matteo@member.fsf.org>
Calls to `IsKeyword("...")` cause runtime construction of std::string.
Avoid possible repeated allocation by pre-allocating keyword strings
during initialization.
In commit v3.4.0-rc2~1^2 (cmIfCommand: Issue CMP0054 warning with
appropriate context, 2015-10-20) we added construction of a
cmListFileContext with conversion of the calling file path. This code
path runs on every condition (e.g. `if()`) and so the path conversion
has a noticeable performance cost. Fortunately the only use of this
context is for insertion into cmMakefile::CMP0054ReportedIds so we do
not need to convert the path. Simply drop the conversion.
b06e17da Help: Add notes for topic 'cmake-depend-in-project-only'
52540245 Tests: Add test for CMAKE_DEPENDS_IN_PROJECT_ONLY variable
b1e1aa1e Makefile: Optionally scan only source and build trees for dependencies
ad140c6e VS: Put ALL_BUILD in the PREDEFINED_TARGETS_FOLDER
f069be05 VS: Fix default target support for targets nested inside a folder
c05ea485 VS: Improve unit test macros
78ec0461 VS: Add option to choose the `.sln` startup project (#15578)
Re-lookup a variable value when an associated VariableWatch is executed
in cmMakefile::GetDefinition.
This fixes a problem with 'def' sometimes becoming invalid due to memory
reallocation inside an std::vector. In this case, the problem was that
if the call to VariableAccessed actually executed a callback function,
the internal state of the makefile has changed due to the associated
function scope being pushed. This in turn implies that a new
cmDefinitions instance was pushed in cmMakefile::VarTree. As
cmLinkedTree is based on an std::vector, this push can have triggered
reallocation of its internal memory buffer. However, as the value of
'def', which was computed on method entry, actually points to a property
of one of the cmDefinitions instances in cmMakefile::VarTree,
reallocation can invalidate the value of 'def' so that it cannot simply
be returned at the end of the function. The solution implemented here is
to simply lookup the value of 'def' again.
This commit fixes a bug in the implementation of the test property
TIMEOUT_AFTER_MATCH. The new timeout value was being applied
every time a line was output by the test after the match had been
encountered. Now the new timeout value is only set once.
This commit also improves some output formatting related to this
property.
51465da1 CPack/IFW: port to cmXMLWriter
754485af cmExtraEclipseCDT4Generator: port to cmXMLWriter
c45671b0 cmGlobalKdevelopGenerator: port to cmXMLWriter
dcdc270e cmExtraCodeLiteGenerator: port to cmXMLWriter
27e09764 cmExtraCodeBlocksGenerator: port to cmXMLWriter
d7407621 cmXMLWriter: add Doctype() method
dd27e313 cmXMLWriter: overload Element() method for empty elements
Add a `VS_STARTUP_PROJECT` directory property to specify the project
that should be placed first in the `.sln` file so that it will be
selected as the default startup project.
Co-Author: Taylor Braun-Jones <taylor.braunjones@avigilon.com>
Some compilers on OS X report errors in the CoreServices framework headers.
Check for support of the header ahead of time and compile the relevant code
only when the header is available.
With the Makefile generator one can use `cd $subdir; make all` to build
all targets associated with a given subdirectory. This is not possible
to do with the Ninja generator since there is only one `build.ninja`
file at the top of the build tree. However, we can approximate it by
allowing one to run `ninja $subdir/all` at the top of the tree to build
the targets in the corresponding subdirectory.
Port logic from cmGlobalUnixMakefileGenerator3::WriteDirectoryRule2 to
cmGlobalNinjaGenerator in order to produce equivalent directory-level
targets.
In commit v3.5.0-rc1~232^2 (CPackDMG: Add support for multilingual SLAs,
2015-10-19) we added use of the Carbon framework in order to get access
to its APIs to convert Script Manager RegionCode values. This is not
necessary. Instead we can use CoreServices.
While at it, replace individual CoreFoundation includes with including
the entire framework, which is the correct way.
Fix the DebuggerTool RemoteExecutable value added by commit a22f9967
(VS: Optionally generate remote directory for WinCE projects,
2016-02-15) to account for the configuration when computing the target
name.
Use cmSystemTools::GetCMakeRoot() which always knows the location of our
resources. Do not depend on CMAKE_ROOT because the user could unset it
from the cache.
Teach the VS 2008 and 2005 generators to set the `RemoteDirectory`
in `DeploymentTool` and the `RemoteExecutable` in `DebuggerTool`.
Use a `DEPLOYMENT_REMOTE_DIRECTORY` target property to specify the
value.
491b41dd Help: Add notes for topic 'vs-clang-cl'
ad6d27ac Tests: do not build PrecompiledHeader on Clang/C2
a0f0541f Tests: fix PDBDirectoryAndName on Clang/C2
3541af67 Tests: fix Plugin building on Clang/C2
1902c293 Tests: fix complexOneConfig building on Clang/C2
cab2ec11 Tests: fix Complex building on Clang/C2
ada3736c Tests: fix Module.GenerateExportHeader building on Clang/C2
123b7e13 Tests: fix AliasTarget building on Clang/C2
445d4d4b VS 14: Add flag map for -std= to CppLanguageStandard tag in project files
0a785eb4 Features: Clang has no cxx_decltype_incomplete_return_type in MSVC sim mode
2c2ec488 VS: in Clang/C2 toolset, setup correct compiler settings
37afe00f CMakeDetermineCompilerId: Add detection of clang.exe bundled with VS
Teach the Ninja generator to add the `-current_version` and the
`-compatibility_version` flags based on the VERSION and SOVERSION target
properties just as the Makefile generators do.
Signed-off-by: Bruce Stephens <bruce.r.stephens@gmail.com>
Move this method from cmMakefileLibraryTargetGenerator so it can be
re-used for the Ninja generator too.
Signed-off-by: Bruce Stephens <bruce.r.stephens@gmail.com>
Calling `project()` or `enable_language()` from a toolchain file will
infinitely recurse since those commands load the toolchain file.
Diagnose and reject this case with an error message instead of crashing
when the stack eventually overflows.
Since commit v3.4.2~2^2 (VS: Fix VS 2015 .vcxproj file value for
GenerateDebugInformation, 2016-01-08) we generate invalid project
files for the v110 and v120 toolsets. VS complains:
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(639,9):
error MSB4030: "Debug" is an invalid value for the "GenerateDebugInformation" parameter of
the "Link" task. The "GenerateDebugInformation" parameter is of type "System.Boolean".
This reveals that our VS flag map selection should be based on the
toolset instead of the version of VS. However, that will be a
non-trivial change so for now fix this particular use case by
hard-coding a correction to the flag map.
Reported-by: Gregor Jasny <gjasny@googlemail.com>
When performing some other testing, the globs for Blanket.js and Delphi
code coverage are picking up unintended files. Change the query for the
Delphi coverage to follow the naming convention, and check the second line
of the found JSON files for certain text before parsing them as coverage files.
Although we fail with an error on a hash mismatch, it is not a fatal
error so the script may continue processing. If the download itself had
no error then report in the STATUS variable that the operation was not
successful due to the hash mismatch.
Suggested-by: Tobias Hieta <tobias@hieta.se>
With this patch, the builtin macros and include dirs are only
added to the project file if the C/CXX langauges are really enabled.
I.e. before this patch the CXX-stuff was in the project file as soon
as CXX had been enabled at least once for this build tree.
I.e. disabling CXX later on did not remove the CXX macros etc.
from the project file (related to #15150)
Alex
Since commit v3.4.2~2^2 (VS: Fix VS 2015 .vcxproj file value for
GenerateDebugInformation, 2016-01-08) we generate invalid project
files for the v110 and v120 toolsets. VS complains:
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(639,9):
error MSB4030: "Debug" is an invalid value for the "GenerateDebugInformation" parameter of
the "Link" task. The "GenerateDebugInformation" parameter is of type "System.Boolean".
This reveals that our VS flag map selection should be based on the
toolset instead of the version of VS. However, that will be a
non-trivial change so for now fix this particular use case by
hard-coding a correction to the flag map.
Reported-by: Gregor Jasny <gjasny@googlemail.com>
This is done the same way as for Eclipse: cmake tries to determine
the number of CPUs, and then adds the respective -jN to the make
invocations in the project file.
Alex
Create a `CMAKE_TRY_COMPILE_TARGET_TYPE` option to specify use
of `add_library(... STATIC ...)` for the generated test project.
This will be useful for cross-compiling toolchains that cannot
link a binary without custom flags or scripts.
This reverts commit 9beb2744d7.
Our AUTOMOC documentation states that it should be possible to
`#include "moc_foo.cpp"` in `foo.cpp`, and this will not work if
the file is placed in a different directory. Another solution
will need to be found to the original problem.
Reported-by: Stephen Kelly <steveire@gmail.com>
The new `%s` format specifier is substituted by file()/string()
`TIMESTAMP` sub-commands with the number of seconds since unix-epoch
(1970-01-01 00:00:00 UTC).
Co-Author: Nils Gladitz <nilsgladitz@gmail.com>
In commit v3.5.0-rc1~43^2 (Fix export of STATIC library PRIVATE
dependencies with CMP0022 NEW, 2016-01-15) we taught
target_link_libraries to generate `$<LINK_ONLY:$<TARGET_NAME:dep>>` in
INTERFACE_LINK_LIBRARIES instead of `$<LINK_ONLY:dep>` so that `dep` can
be recognized as a target name and updated during export. However, this
approach does not work when `dep` is just a plain library name and not a
target because `$<TARGET_NAME:...>` requires the name of a reachable
target.
Since we do not know during target_link_libraries whether the name will
correspond to a reachable target or not, we cannot inject the
`$<TARGET_NAME:...>` expression. Revert this change and solve the
original problem instead by teaching the export logic to recognize and
update target names directly in `$<LINK_ONLY:...>` expressions.
Reported-by: Ben Boeckel <ben.boeckel@kitware.com>
More elaborate selection of the `compiler` tag in the generated
CodeBlocks project file:
* Fortran language support
* support for several of the predefined compilers recognized by
CodeBlocks (16.01)
The re-implementation in commit v3.5.0-rc1~116^2~1 (CMakeParseArguments:
replace by native cmake_parse_arguments command, 2015-12-05) introduced
a regression when parsing the ARGN arguments with cmake_parse_arguments.
The original implementation used
foreach(currentArg ${ARGN})
to iterate over input arguments. This flattened ;-lists within the
arguments whether they were quoted or not. Fix our new implementation
to preserve this behavior and add a test case to cover it.
Signed-off-by: Dimitar Yordanov <dimitar.yordanov@sap.com>
Signed-off-by: Matthias Maennich <matthias.maennich@sap.com>
Refactoring in commit v3.3.0-rc1~29^2~1 (cmState: Host some state from
the cmGlobalGenerator, 2015-05-24) moved storage of some generator
traits over to cmState. However, it accidentally removed initialization
of the values from the cmGlobalGenerator constructor. This is needed
because generator subclasses update the settings in their constructors.
Since a single cmState instance is shared across multiple build trees by
cmake-gui, initializing the values in its constructor is not enough.
Fix this by restoring the needed initializations to the
cmGlobalGenerator constructor.
We represent target dependency sets as `set<cmTargetDepend>` which
orders by a `cmGeneratorTarget const*` pointer value. Therefore the
order of dependencies encountered in AppendTargetDepends is not
predictable. Sort them by content to make the result deterministic.
Generate custom command build statements in the order we encounter
source files specifying them. Do not depend on pointer values of
internally allocated structures for ordering.
This version introduced CURLE_NOT_BUILT_IN which we have used since
commit v3.4.0-rc1~211^2~4 (cmCurl: Tolerate lack of CURLOPT_CAPATH
support, 2015-08-12). For older versions, just define the name to the
then-unused error code so that we can compile.
a1ad098d Tests: Avoid OS X 10.5 limitation warning in RunCMake.install test
47460f3e install(EXPORT): Fix crash on target in another directory
e86383e1 Tests: Use newer policy settings in RunCMake.install test
In commit v3.5.0-rc1~272^2~6 (cmGlobalGenerator: Add FindGeneratorTarget
API, 2015-10-25) a lookup was implemented via linear search. Replace it
with an efficient data structure.
Suggested-by: Stephen Kelly <steveire@gmail.com>
Refactoring in commit v3.5.0-rc1~272^2~13 (cmGlobalGenerator: Remove
direct storage of targets, 2015-10-25) replaced an efficient data
structure mapping from target name to cmTarget instance with a linear
search. Lookups through cmGlobalGenerator::FindTarget are done a lot.
Restore the efficient mapping structure with a name indicating its
purpose.
Reported-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
Previously we did not clearly document that `--target` is only supported
to be specified once. Even worse, specifying it multiple times would
silently ignore any previously specified targets and only build the last
target.
Update the documentation to specify this. Update the implementation to
reject multiple `--target` options to prevent user errors.
Refactoring merged by commit v3.5.0-rc1~299 (Merge topic
'use-generator-target', 2015-10-20) in and around
commit v3.5.0-rc1~299^2~13 (cmExportSet: Store a cmGeneratorTarget,
2015-10-17) changed export sets to delay looking up actual targets and
stores only their names. However, in InstallCommand::HandleExportMode
we need to lookup targets immediately to check them for
EXPORT_LINK_INTERFACE_LIBRARIES. The check was accidentally made local
to the current directory, so if an export set contains a target from
another directory the lookup fails and CMake crashes. Fix the check to
look up the target name globally, and tolerate when no target is found
just in case.
Reported-by: Kelly Thompson <kgt@lanl.gov>
Refactoring in commit v3.5.0-rc1~347^2~2 (Set the current dirs on the
snapshot before creating the cmMakefile) accidentally changed the
source and binary directories configured in `cmake -E cmake_depends`
for use during dependency scanning. This can cause the wrong directory
information to be loaded. It also breaks Fortran module dependency
scanning for modules provided by targets in subdirectories that do
not have Fortran_MODULE_DIRECTORY set.
Fix the dependency scanning directory configuration and add a test to
cover the Fortran module case in which the breakage was observed.
Reported-by: Kelly Thompson <kgt@lanl.gov>
Let us take an example of a project that has some tests in a component
that need to be installed into a dedicated test package. The user
expectation is that the result could be achieved by typing the
following:
make
make tests
make install
DESTDIR=/testpkgs make install-tests
However this results in test components in the default installation as
well as the testpkg.
Add an EXCLUDE_FROM_ALL option to the install() command to tell it that
the installation rule should not be included unless its component is
explicitly specified for installation.
While evaluating `if(MATCHES)` we get a `const char*` pointer to the
string to be matched. On code like
if(CMAKE_MATCH_COUNT MATCHES "Y")
the string to be matched may be owned by our own result variables.
We must move the value to our own buffer before clearing them.
Otherwise we risk reading freed storage.
The add_custom_command(TARGET) signature only works for targets defined
in the current directory. Clarify this in the error message when the
target exists but was defined elsewhere.
Inspired-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
70788e92 Remove temporary allocations when calling cmHasLiteral{Suf,Pre}fix.
bd2384f5 Optimize cmMakefile::ExpandVariablesInStringNew.
ad9394f4 Remove temporary allocations in cmMacroHelper::InvokeInitialPass.
f9599ed4 Remove temporary allocations by extending the lifetime of the retval.
275f2a85 Remove temporary allocations when calling cmGeneratorTarget::GetName.
Since commit v3.4.0-rc1~5^2~1 (VS: Add support for selecting the Windows
10 SDK, 2015-09-30) the VS 2015 generator requires a Windows 10 SDK to
be available when CMAKE_SYSTEM_VERSION specifies Windows 10 (e.g. when
building on a Windows 10 host). Howewver, it is possible to install VS
2015 without any Windows 10 SDK. Instead of failing with an error
message about the lack of a Windows 10 SDK, simply tolerate this case
and use the default Windows 8.1 SDK. Since building for Windows Store
still requires the SDK, retain the diagnostic in that case.
Refactoring merged by commit 9afbb733ec (Merge topic
'use-generator-target', 2015-10-20) in and around commit 381e7afd
(cmExportSet: Store a cmGeneratorTarget, 2015-10-17) forgot to update
one place in this method. This leads to a crash in code such as
add_library(A a.c)
add_library(B b.c)
target_link_libraries(B A)
install(TARGETS B DESTINATION lib EXPORT ExpB)
install(EXPORT ExpB DESTINATION lib/cmake/test)
add_executable(C c.c)
install(TARGETS C DESTINATION bin EXPORT ExpC)
Fix the target name reference to avoid using an unpopulated Target
pointer.
When the first argument passed is a std::string, we need to take it
by const&, otherwise we copy the string and trigger a temporary
allocation. This patch removes a few 10k temporary allocations when
running the CMake daemon on the KDevelop build dir.
This hotspot was found with heaptrack.
We can remove the temporary allocations required for the
default-constructed t_lookup passed into the openstack by refactoring
the code slightly. Furthermore, we use a vector instead of a stack,
since the latter is based on a deque which is not required for a
heap / lifo structure.
This patch removes ~215k allocations.
This hotspot was found with heaptrack.
This code used to convert std::string's to raw C strings only to
put that back into a std::string. This patch thus removes ~70k
temporary allocations when running the CMake daemon on KDevelop.
This hotspot was found with heaptrack.
Kitware Robot
Brad King
Daniel Pfeifer
Geoff Viola
Sebastian Holtermann
Rolf Eike Beer
Stafen Teleman
Dmitry Ivanov
Ben Boeckel
Patrik Lehmann
Zack Galbreath
Felix Geyer
Yves Frederix
Taylor Braun-Jones
Attila Krasznahorkay
Davy Durham
Charles Huet
Sean McBride
Andrej Bosik
Mariusz Pluciński
Gregor Jasny
Bruce Stephens
Fabian Otto
Joseph Snyder
Alex Neundorf
Robert Goulet
Cristian Rodríguez
Jose-Luis Blanco-Claraco
Daniel Wirtz
Melven Roehrig-Zoellner
Dimitar Yordanov
Tobias Hunger
Sebastian Schuberth
Christoph Grüninger
Nick Lewis
Ashley Whetter
Andrey Pokrovskiy
Milian Wolff