1. 15 Apr, 2016 9 commits
    • Brad King's avatar
      cmState: Avoid accumulating snapshot storage for backtraces · 1f6bd8a9
      Brad King authored
      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
          foreach(i RANGE 1000000)
      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.
    • Brad King's avatar
      cmState: Add Snapshot method to get bottom of call stack · 18b6676b
      Brad King authored
      The bottom of the call stack is always a long-lived snapshot and can be
      saved for later use with cmOutputConverter.
    • Brad King's avatar
      Add call stack to unused/uninitialized variable warnings · 2faa8b36
      Brad King authored
      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.
    • Brad King's avatar
      cmLocalGenerator: Simplify IssueMessage implementation · da07c506
      Brad King authored
      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.
    • Brad King's avatar
      cmLocalGenerator: Use own IssueMessage method · cc7aed77
      Brad King authored
    • Brad King's avatar
      cmOutputConverter: Assert construction with a valid snapshot · c50285de
      Brad King authored
      We unconditionally use information from the snapshot so it must be
    • Brad King's avatar
      cmMakefile: Move cmMakefileCall to .cxx file · b6ed71b1
      Brad King authored
    • Brad King's avatar
      cmWhileCommand: Simplify context construction · a559f0f6
      Brad King authored
    • Brad King's avatar
  2. 13 Apr, 2016 6 commits
  3. 12 Apr, 2016 2 commits
  4. 11 Apr, 2016 7 commits
  5. 10 Apr, 2016 1 commit
  6. 09 Apr, 2016 1 commit
  7. 08 Apr, 2016 9 commits
  8. 07 Apr, 2016 5 commits