GitLab

This information is now kept in cmMakefile::Backtrace.

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.

The bottom of the call stack is always a long-lived snapshot and can be
saved for later use with cmOutputConverter.

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.

We unconditionally use information from the snapshot so it must be
valid.

Brad King authored Apr 13, 2016 and Kitware Robot committed Apr 13, 2016

c54ed781 cmState: Rename CallStack snapshots to IncludeFile

Brad King authored Apr 13, 2016 and Kitware Robot committed Apr 13, 2016

bd581a37 try_compile: Honor CMAKE_<LANG>_FLAGS_<CONFIG> changes (#16054)
82ef90fc cmCoreTryCompile: Factor out config lookup for re-use

Brad King authored Apr 13, 2016 and Kitware Robot committed Apr 13, 2016

87549054 FindMPI: Improve documentation formatting

Brad King authored Apr 13, 2016 and Kitware Robot committed Apr 13, 2016

5e62444c Add options to run clang-tidy with the compiler

Daniel Pfeifer authored Apr 08, 2016 and Brad King committed Apr 13, 2016

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`).

Store the lookup of CMAKE_TRY_COMPILE_CONFIGURATION in a local variable
so we can re-use it.

Brad King authored Apr 11, 2016 and Kitware Robot committed Apr 11, 2016

f5e79004 Tests: Work around filesystem timestamp bugs in RunCMake.BuildDepends

Brad King authored Apr 11, 2016 and Kitware Robot committed Apr 11, 2016

aff4a5fa cmConditionEvaluator: Use pre-allocated keywords in more places

Brad King authored Apr 11, 2016 and Kitware Robot committed Apr 11, 2016

a1c40291 GetPrerequisites: Look for VS tools using environment variables
c79f88b0 GetPrerequisites: add path of VS 10,11,12,14 in order to find dumpbin.exe

The Custom-Symbolic-and-Byproduct case fails strangely on some
filesystems used by our nightly testing.  Somehow on the first build the
`use-byproduct` output ends up with a timestamp older than
`gen-byproduct-stamp` even though the build log clearly shows them build
in the correct order (and must according to build system dependencies).
Work around this problem by adding an extra delay before building
`use-byproduct`.
Tested-by: Gerhard Grimm <gerhard.grimm@detec.com>

Inspired-by: Harry Mallon <Harry@codexdigital.com>

Brad King authored Apr 08, 2016 and Kitware Robot committed Apr 08, 2016

add7abc8 Ninja: Restat custom command byproducts even with a SYMBOLIC output (#16049)
ff805113 Ninja: Fix detection of custom command symbolic outputs

Brad King authored Apr 08, 2016 and Kitware Robot committed Apr 08, 2016

e888af97 MSVC: Drop space in `/DNDEBUG` flag for consistency (#16052)

Brad King authored Apr 08, 2016 and Kitware Robot committed Apr 08, 2016

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 `VS*COMNTOOLS` environment variables specify locations of VS tools
and are set during the VS installation.  Use them in addition to the
hard-coded default install locations.

We define `NDEBUG` without a space after the `-D` option for most
compilers.  Remove the space for MSVC (and Intel Fortran) for
consistency.  The MS compiler technically does not document that
the `-D` argument may be separated from its value, though every
version to date supports it.

Dmitry Ivanov authored Apr 06, 2016 and Brad King committed Apr 07, 2016

Update the WriteBuild method to use a negative command line length limit
to specify that we should force use of response files.