1. 03 Apr, 2013 2 commits
  2. 02 Apr, 2013 4 commits
  3. 01 Apr, 2013 1 commit
  4. 31 Mar, 2013 1 commit
  5. 30 Mar, 2013 1 commit
  6. 29 Mar, 2013 3 commits
  7. 28 Mar, 2013 11 commits
  8. 27 Mar, 2013 2 commits
  9. 26 Mar, 2013 11 commits
  10. 25 Mar, 2013 4 commits
    • Brad King's avatar
      VS: Fix VS 10/11 .sln headers (#14038) · c677838c
      Brad King authored
      The VS version we generate in the .sln header is used by VS when opening
      the file through Windows Explorer and possibly elsewhere.  Fix our
      generators to use version strings known to VS to avoid a drop-down box.
      For VS 10, since commit 4f96af44 (Fix VS 10 .sln files for Windows
      Explorer, 2009-10-22) we use "Visual Studio 2010" instead of just
      "Visual Studio 10".  This is correct except that for the Express edition
      we need "Visual C++ Express 2010".
      For VS 11, since commit f0d66ab4 (VS11: Fix comment generated at the top
      of *.sln files, 2011-10-20) we use "Visual Studio 11" in the .sln header
      but the preferred value is "Visual Studio 2012" (just as the first
      commit mentioned above fixed for VS 10).  Also for the Express edition
      we need "Visual Studio Express 2012 for Windows Desktop".
    • Stephen Kelly's avatar
      Fix new target commands documentation. · 2e80f9f2
      Stephen Kelly authored
      The target_include_directories and target_compile_defintions commands
      accepted targets as arguments until commit f6b16d4b (Don't allow
      targets args in the new target commands., 2013-01-29). This followed
      from discussion on the mailing list (target_include_directories() accepts
      only absolute paths ?, 2013-01-28):
      It was also decided to allow relative paths in target_include_directories().
    • Brad King's avatar
      Test evaluation of per-config COMPILE_DEFINITIONS (#14037) · 1703b00c
      Brad King authored
      Teach the CompileDefinitions test to cover evaluation of config-specific
      generator expressions.
    • Stephen Kelly's avatar
      Fix the evaluation of per-config COMPILE_DEFINITIONS (#14037) · a6286e92
      Stephen Kelly authored and Brad King's avatar Brad King committed
      The API for retrieving per-config COMPILE_DEFINITIONS has long
      existed because of the COMPILE_DEFINITIONS_<CONFIG> style
      properties. Ensure that the provided configuration being generated
      is also used to evaluate the generator expressions
      in cmTarget::GetCompileDefinitions.
      Both the generic COMPILE_DEFINITIONS and the config-specific
      variant need to be evaluated with the requested configuration. This
      has the side-effect that the COMPILE_DEFINITIONS does not need to
      be additionally evaluated with no configuration, so the callers can
      be cleaned up a bit too.