1. 09 Sep, 2016 1 commit
  2. 08 Sep, 2016 1 commit
  3. 07 Sep, 2016 1 commit
    • Brad King's avatar
      VS15: Add Visual Studio 15 generator · bdc679a8
      Brad King authored
      Call the generator "Visual Studio 15" without any year because the
      preview version of VS 15 does not provide a year in the product name.
      Copy cmGlobalVisualStudio14Generator to cmGlobalVisualStudio15Generator
      and update version numbers accordingly.  Add the VS15 enumeration value.
      Note that we do not need to add a MSVC15 variable or v150 toolset
      because Visual Studio 15 comes with an updated version of the v140
      toolset and remains ABI-compatible.
      Teach tests VSExternalInclude, RunCMake.GeneratorPlatform, and
      RunCMake.GeneratorToolset to treat VS 15 as they do VS 10-14.
      Closes: #16143
  4. 06 Sep, 2016 1 commit
    • Brad King's avatar
      cmMakefile: Restore nested error logic use of cmExecutionStatus · f1ad71d7
      Brad King authored
      Since commit 14a8d61f (cmMakefile: Port nested error logic away from
      cmExecutionStatus) we fail to continue processing function and macro
      bodies after non-fatal errors.  A non-fatal error should not stop
      foreach loops, macro bodies, nested bodies, or the outer script.
      Add a test covering these cases, and revert the change to fix them.
      Also revert commit 2af853de (cmMakefile: Simplify IssueMessage
      implementation) because the assertion it added (which was removed by the
      above commit and is restored by reverting it) is incorrect.  We do have
      code paths that call cmMakefile::IssueMessage with an empty execution
      stack, such as in CheckForUnusedVariables's LogUnused call.
  5. 05 Sep, 2016 4 commits
  6. 31 Aug, 2016 1 commit
  7. 30 Aug, 2016 2 commits
  8. 26 Aug, 2016 1 commit
  9. 25 Aug, 2016 1 commit
  10. 24 Aug, 2016 1 commit
  11. 23 Aug, 2016 2 commits
  12. 16 Aug, 2016 1 commit
  13. 09 Aug, 2016 2 commits
    • Chaoren Lin's avatar
      Tests: Fix RunCMake.Framework on case sensitive file systems. · 677e73cb
      Chaoren Lin authored and Brad King's avatar Brad King committed
      The file is lowercase: Tests/RunCMake/Framework/osx.cmake
    • Brad King's avatar
      Ninja: Add `$subdir/{test,install,package}` targets · 02789894
      Brad King authored
      With the Makefile generator one can use `cd $subdir; make install` to build and
      install targets associated with a given subdirectory.  This is not possible to
      do with the Ninja generator since there is only one `build.ninja` file at the
      top of the build tree.  However, we can approximate it by allowing one to run
      `ninja $subdir/install` at the top of the tree to build the targets in the
      corresponding subdirectory and install them.
      This also makes sense for `test`, `package`, and other GLOBAL_TARGET targets.
      It was already done for `all` by commit v3.6.0-rc1~240^2~2 (Ninja: Add
      `$subdir/all` targets, 2016-03-11).
  14. 08 Aug, 2016 1 commit
  15. 27 Jul, 2016 1 commit
    • Daniel Pfeifer's avatar
      Use string(APPEND) in Tests · 7a649111
      Daniel Pfeifer authored
      Automate with:
      find Tests -type f -print0 | xargs -0 perl -i -0pe \
      's/set\(([a-zA-Z0-9_]+)(\s+)"\$\{\1\}([^"])/string(APPEND \1\2"\3/g'
  16. 22 Jul, 2016 1 commit
  17. 21 Jul, 2016 2 commits
  18. 20 Jul, 2016 1 commit
    • Brad King's avatar
      Ninja: Fix inter-target order-only dependencies of custom commands · 1296a0ea
      Brad King authored
      Custom command dependencies are followed for each target's source files
      and add their transitive closure to the corresponding target.  This
      means that when a custom command in one target has a dependency on a
      custom command in another target, both will appear in the dependent
      target's sources.  For the Makefile, VS IDE, and Xcode generators this
      is not a problem because each target gets its own independent build
      system that is evaluated in target dependency order.  By the time the
      dependent target is built the custom command that belongs to one of its
      dependencies will already have been brought up to date.
      For the Ninja generator we need to generate a monolithic build system
      covering all targets so we can have only one copy of a custom command.
      This means that we need to reconcile the target-level ordering
      dependencies from its appearance in multiple targets to include only the
      least-dependent common set.  This is done by computing the set
      intersection of the dependencies of all the targets containing a custom
      command.  However, we previously included only the direct dependencies
      so any target-level dependency not directly added to all targets into
      which a custom command propagates was discarded.
      Fix this by computing the transitive closure of dependencies for each
      target and then intersecting those sets.  That will get the common set
      of dependencies.  Also add a test to cover a case in which the
      incorrectly dropped target ordering dependencies would fail.
  19. 14 Jul, 2016 1 commit
  20. 11 Jul, 2016 1 commit
  21. 10 Jul, 2016 1 commit
  22. 06 Jul, 2016 1 commit
    • Brad King's avatar
      Honor CMAKE_<LANG>_FLAGS[_<CONFIG>]_INIT set in toolchain files · a66004be
      Brad King authored
      Document these variables.
      Change our convention for setting these variables from:
          set(CMAKE_C_FLAGS_INIT "...")
          string(APPEND CMAKE_C_FLAGS_INIT " ...")
      so that any value previously set by a toolchain file will be used.
      Automate the conversion with:
          sed -i 's/set *(\(CMAKE_\(C\|CXX\|Fortran\|RC\|ASM\|${[^}]\+}\)_FLAGS\(_[^_]\+\)\?_INIT \+"\)/string(APPEND \1 /' \
            Modules/Compiler/*.cmake Modules/Platform/*.cmake
      and follow up with some manual fixes (e.g. to cases that already
      meant to append).  Also revert the automated changes to contexts
      that are not protected from running multiple times.
  23. 29 Jun, 2016 1 commit
    • Brad King's avatar
      try_compile: Add policy CMP0066 to honor CMAKE_<LANG>_FLAGS_<CONFIG> · d582c23a
      Brad King authored
      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`).
      However, some projects may currently depend on this not being done,
      so we need to activate the behavior using a policy.
      This change was originally made by commit v3.6.0-rc1~160^2 (try_compile:
      Honor CMAKE_<LANG>_FLAGS_<CONFIG> changes, 2016-04-11) but without the
      policy and so had to be reverted during the 3.6 release candidate cycle.
      Fixes #16174.
  24. 28 Jun, 2016 1 commit
    • Brad King's avatar
      Revert "try_compile: Honor CMAKE_<LANG>_FLAGS_<CONFIG> changes" · 943fe6e3
      Brad King authored
      Revert commit v3.6.0-rc1~160^2 (try_compile: Honor
      CMAKE_<LANG>_FLAGS_<CONFIG> changes, 2016-04-11).  The behavior it
      introduced can break projects that depend on the lack of such behavior.
      We will have to introduce a policy or other mechanism to enable the
      behavior in a compatible way.  Simply revert it for now.
      See issue #16174.
  25. 20 Jun, 2016 2 commits
  26. 17 Jun, 2016 2 commits
    • Alex Turbov's avatar
      cmake: Add an option to control what files needs to be traced · e63151ff
      Alex Turbov authored and Brad King's avatar Brad King committed
      Even in relatively small projects using `--trace` (and `--trace-expand`)
      may produce a lot of output.  When developing a custom module usually
      one is interested in output of only a few particular modules.
      Add a `--trace-source=<file>` option to enable tracing only a subset of
      source files.  The final output would be only from requested modules,
      ignoring anything else not matched to given filename(s).
    • Bill Hoffman's avatar
      Add options to run `ldd -u -r` as a "link-what-you-use" tool · 96242f80
      Bill Hoffman authored and Brad King's avatar Brad King committed
      Create a LINK_WHAT_YOU_USE target property and corresponding
      CMAKE_LINK_WHAT_YOU_USE variable to enable this behavior.
      Extend link commands by running `ldd -u -r` to detect shared
      libraries that are linked but not needed.
  27. 13 Jun, 2016 1 commit
  28. 12 Jun, 2016 1 commit
    • Stephen Kelly's avatar
      cmake: Issue message independent of cmMakefile definition · 0a4af073
      Stephen Kelly authored
      The makefile is only used when called by the cmMessageCommand, so inline
      the use of it there.  It otherwise creates an undesirable dependency on
      cmMakefile for issuing messages in the cmake instance, a violation of
      the Interface Segregation Principle.
      This also makes it more explicit that the variable definitions only
      affect the message() command.  If an AUTHOR_WARNING is issued for any
      other reason, it is not affected.  To affect that, it is necessary to
      set the cache variable instead of the regular variable.
      This is an unfortunate interface quirk, but one which can't be fixed
      easily now.
  29. 10 Jun, 2016 1 commit
  30. 07 Jun, 2016 1 commit
  31. 02 Jun, 2016 1 commit
    • Brad King's avatar
      Fix crash on $<TARGET_PROPERTY:...,LOCATION> genex (#16134) · f500a784
      Brad King authored
      Policy CMP0026 deprecated the LOCATION property, and we have long
      provided a $<TARGET_FILE:...> generator expression.  However, if
      a project tries to use $<TARGET_PROPERTY:...,LOCATION> we should
      at least not crash.
      The compatibility implementation of the LOCATION property uses
      cmGlobalGenerator::CreateGenerationObjects to create the structures
      needed to evaluate the property before generation starts.  The
      implementation assumed that accessing the property could only be done
      during configuration (via the typical get_property command use case).
      The $<TARGET_PROPERTY:...,LOCATION> genex causes the LOCATION property
      to be accessed during generation.  Calling CreateGenerationObjects
      during generation blows away all the objects currently being used for
      generation and is not safe.  Add a condition to call it only when
      configuration is not finished.