1. 20 Oct, 2015 1 commit
    • Stephen Kelly's avatar
      cmIfCommand: Issue CMP0054 warning with appropriate context. (#15802) · d6a03b47
      Stephen Kelly authored
      Commit v3.4.0-rc1~494^2~4 (cmMakefile: Add API for elseif to create
      backtrace., 2015-05-29) removed the use of cmMakefileCall to push/pop
      execution context in favor of a new way to create backtraces.
      However, a call to cmMakefile::GetExecutionContext is still invoked to
      issue a contextual CMP0054 warning through cmConditionEvaluator.  As
      the elseif is not part of the call stack, this resulted in trying to
      access an empty vector.
      Avoid the attempt at getting execution context when evaluating elseif by
      constructing a context and backtrace on behalf of the cmConditionEvaluator
      in all cases.
  2. 06 Jul, 2015 2 commits
  3. 06 Jun, 2015 1 commit
  4. 02 Jun, 2015 1 commit
  5. 14 May, 2015 1 commit
  6. 22 Feb, 2015 1 commit
  7. 18 Jan, 2015 2 commits
  8. 01 Dec, 2014 1 commit
  9. 11 Sep, 2014 2 commits
  10. 29 Apr, 2014 1 commit
    • Ben Boeckel's avatar
      ClearMatches: Only clear matches which were actually set · f718b30a
      Ben Boeckel authored
      ClearMatches was clearing many variables which were never set in the
      first place. Instead, store how many matches were made last time and
      only clear those. It is moved to the cmMakefile class since it is a
      common utility used by multiple commands.
  11. 11 Mar, 2014 1 commit
    • Stephen Kelly's avatar
      Remove some c_str() calls. · 21c573f6
      Stephen Kelly authored
      Use the clang RemoveCStrCalls tool to automatically migrate the
      code. This was only run on linux, so does not have any positive or
      negative effect on other platforms.
  12. 08 Mar, 2014 1 commit
  13. 16 Jan, 2014 1 commit
    • Rolf Eike Beer's avatar
      cmMakefile: make some methods take const std::string& instead of const char* · c768e398
      Rolf Eike Beer authored
      Most callers already have a std::string, on which they called c_str() to pass it
      into these methods, which internally converted it back to std::string. Pass a
      std::string directly to these methods now, avoiding all these conversions.
      Those methods that only pass in a const char* will get the conversion to
      std::string now only once.
  14. 12 Jun, 2013 1 commit
  15. 11 Sep, 2012 1 commit
  16. 16 May, 2012 1 commit
  17. 22 Jan, 2012 1 commit
  18. 28 Jan, 2010 1 commit
  19. 28 Oct, 2009 2 commits
  20. 27 Oct, 2009 2 commits
    • Brad King's avatar
      Fix if() command and CMP0012 OLD/NEW behavior · cb185d93
      Brad King authored
      The commit "modified the if command to address bug 9123 some" changed
      the if() command behavior with respect to named boolean constants.  It
      introduced policy CMP0012 to provide compatibility.  However, it also
      changed behavior with respect to numbers (like '2') but did not cover
      the change with the policy.  Also, the behavior it created for numbers
      is confusing ('2' is false).
      This commit teaches if() to recognize numbers again, and treats them
      like the C language does in terms of boolean conversion.  We also fix
      the CMP0012 check to trigger in all cases where the result of boolean
      coersion differs from that produced by CMake 2.6.4.
    • Brad King's avatar
      Report expanded arguments in if() command errors · 9f43fa60
      Brad King authored
      The if() command reports its arguments at the beginning of some error
      messages.  Originally it reported the un-expanded form of the arguments
      because in ancient CMake versions no context information was available.
      Now it is more useful to see the real arguments, which may be mentioned
      in the main error message.  Since full context information is now
      available, users can refer back to the source if they need to see the
      unexpanded form of the arguments.
      For example, the code
        set(regex "++")
        if("x" MATCHES "${regex}")
      now produces the message
        if given arguments:
          "x" "MATCHES" "++"
        Regular expression "++" cannot compile
      instead of
        if given arguments
          "x" MATCHES "${regex}"
        Regular expression "++" cannot compile
  21. 21 Oct, 2009 1 commit
  22. 09 Oct, 2009 1 commit
  23. 02 Oct, 2009 1 commit
    • Brad King's avatar
      Clarify documentation and message for CMP0012 · 3d3efbd3
      Brad King authored
      This commit re-words the warning message produced for CMP0012 to avoid
      the word 'you' since often the person reading the message is not the
      author of the code.  We also add an example of the bad OLD behavior to
      the policy documentation.
  24. 01 Oct, 2009 1 commit
  25. 28 Sep, 2009 1 commit
    • Brad King's avatar
      Convert CMake to OSI-approved BSD License · 96afb120
      Brad King authored
      This converts the CMake license to a pure 3-clause OSI-approved BSD
      License.  We drop the previous license clause requiring modified
      versions to be plainly marked.  We also update the CMake copyright to
      cover the full development time range.
  26. 17 Jun, 2009 1 commit
    • Brad King's avatar
      ENH: Improve format of if() command messages · 3c856405
      Brad King authored
      Errors and warnings from the if() command always display the argument
      list given to the command followed by an explanation of the problem.
      This moves the argument list into a pre-formatted block and follows it
      with a paragraph-form explanation.  The result looks cleaner.
  27. 12 Jun, 2009 2 commits
  28. 21 Jan, 2009 2 commits
    • Brad King's avatar
      ENH: Better handling of mismatched blocks · 1dcc5b45
      Brad King authored
      If a logical block terminates with mismatching arguments we previously
      failed to remove the function blocker but replayed the commands anyway,
      which led to cases in which we failed to report the mismatch (return
      shortly after the ending command).  The recent refactoring of function
      blocker deletion changed this behavior to produce an error on the ending
      line by not blocking the command.  Furthermore, the function blocker
      would stay in place and complain at the end of every equal-level block
      of the same type.
      This teaches CMake to treat the begin/end commands (if/endif, etc.) as
      correct and just warns when the arguments mismatch.  The change allows
      cases in which CMake 2.6.2 silently ignored a mismatch to run as before
      but with a warning.
    • Brad King's avatar
      ENH: Better error message for unclosed blocks · bca10262
      Brad King authored
      This centralizes construction of the error message for an unclosed
      logical block (if, foreach, etc.).  We record the line at which each
      block is opened so it can be reported in the error message.
  29. 20 Jan, 2009 2 commits
    • Brad King's avatar
      ENH: Refactor function blocker deletion · 2c81e5fb
      Brad King authored
      When a function blocker decides to remove itself we previously removed
      it at every return point from the C++ scope in which its removal is
      needed.  This teaches function blockers to transfer ownership of
      themselves from cmMakefile to an automatic variable for deletion on
      return.  Since this removes blockers before they replay their commands,
      we no longer need to avoid running blockers on their own commands.
    • Brad King's avatar
      ENH: Improve response to bad if or elseif · a541cac3
      Brad King authored
      Previously bad arguments to an if() or elseif() would cause some
      subsequent statements in the corresponding block to execute.  This
      teaches CMake to stop processing commands with a fatal error.  It also
      provides context to bad elseif() error messages.
  30. 01 Oct, 2008 1 commit
  31. 10 Sep, 2008 1 commit
    • Brad King's avatar
      ENH: Add version comparison to if() command · 4fa96dbf
      Brad King authored
      the if() command.  This simplifies component-wise comparison of version
      numbers in the form "major[.minor[.patch[.tweak]]]".
  32. 20 Aug, 2008 1 commit
    • Brad King's avatar
      ENH: Add if(TARGET) command · fff812db
      Brad King authored
      It is useful to be able to test if a target has been created.  Often
      targets are created only inside conditions.  Rather than storing the
      result of the condition manually for testing by other parts of the
      project, it is much easier for the other parts to just test for the
      target's existence.  This will also be useful when find-modules start
      reporting results with IMPORTED targets and projects want to test if a
      certain target is available.