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>
Imported targets are now the recommended way of dealing with external
library dependencies. Add one for FindPNG and update documentation
accordingly. Also add a test case activated by CMake_TEST_FindPNG.
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.
CMake 3.4 may crash on this case. The problem seems to have been
fixed since then, but keep it working by adding a test case now.
Reported-by: Gonzalo Garramuño <ggarra13@gmail.com>
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.
This happens quite often from within comparisons such as in
NamedGeneratorTargetFinder or FindGeneratorTargetImpl. It is the
top hotspot of both, number of allocations as well as number of
temporary allocations - the majority of calls lead to temporary
allocations.
In raw numbers, this patch removes ~1E6 temporary allocations of
1.5E6 temporary allocations in total when running the cmake daemon
on the KDevelop build dir. That is 2/3 of the total.
This hotspot was found with heaptrack.