1. 08 Sep, 2011 2 commits
  2. 02 Sep, 2011 1 commit
    • Brad King's avatar
      Set CMAKE_<lang>_COMPILER_ID for VS generators · 38aab379
      Brad King authored
      Currently the VS generators do not support Intel C/C++ .icproj files and
      the MS tools do not include a Fortran compiler.  Therefore we can always
      set the C and CXX compiler IDs to "MSVC" and the Fortran ID to "Intel".
      This fixes a regression in support for the Intel Fortran compiler under
      the VS plugin introduced by commit cd43636c (Modernize Intel compiler
      info on Windows, 2010-12-16).  The commit moved the compiler information
      into platform files that only load when the proper compiler id is set.
      It worked for the NMake Makefiles generator but not for the VS IDE
      generator because it did not set the compiler id.
  3. 01 Sep, 2011 1 commit
    • Todd Gamblin's avatar
      FindBoost: Call find_package with NO_MODULE first · 7da796d1
      Todd Gamblin authored and Brad King's avatar Brad King committed
      FindBoost now attempts to find Boost using find_package(Boost NO_MODULE)
      before it does a module mode search.
      User can now set any of these to Boost's install prefix to detect it in module
      or config mode:
      - Boost_DIR  for consistency with other CMake modules
      - BOOST_ROOT or BOOSTROOT for adherence to boost convention
  4. 29 Aug, 2011 3 commits
  5. 27 Aug, 2011 2 commits
  6. 25 Aug, 2011 6 commits
  7. 24 Aug, 2011 1 commit
  8. 23 Aug, 2011 5 commits
  9. 22 Aug, 2011 3 commits
    • Alexander Neundorf's avatar
      Fix --find-package mode on Cygwin, where enable_language(RC) is called · 59238dc2
      Alexander Neundorf authored
      In --find-package mode we can't enable a language, since a lot of
      stuff has not been set up, e.g. which make tool to use.
      So disable enable_language() in this mode.
    • David Cole's avatar
      CheckSymbolExists: Use IMMEDIATE flag for configure_file (#11333) · 6b3993b0
      David Cole authored
      The test "complex" sets the variable CMAKE_BACKWARDS_COMPATIBILITY
      to 1.4. When that variable is set, configure_file does not default
      to IMMEDIATE mode processing. And so, the output file likely does
      not exist yet by the time the next line in the CMakeLists.txt file
      is processed. When that next line is "try_compile" on that file,
      this is a problem.
      Fix the problem by explicitly using IMMEDIATE in the configure_file
      This problem was quite mysterious, as it only showed up on the
      "complex" test, when the previous commit introduced a CheckSymbolExists
      call into the FindThreads module. Which is not even explicitly included
      in the "complex" test... FindThreads gets included indirectly only
      as a side effect of setting CMAKE_BACKWARDS_COMPATIBILITY to 1.4 and
      even then it's included indirectly by auto-inclusion of
      Wow. Just wow.
    • Alexander Neundorf's avatar
      Require the current cmake version in --find-package mode · 98472e45
      Alexander Neundorf authored
      This fixes the problem that otherwise Platforms/CYGWIN.cmake doesn't
      know whether it should set WIN32 or not.
      Now it uses always the current behaviour.
  10. 20 Aug, 2011 1 commit
  11. 18 Aug, 2011 1 commit
  12. 16 Aug, 2011 2 commits
  13. 15 Aug, 2011 7 commits
  14. 14 Aug, 2011 2 commits
  15. 13 Aug, 2011 3 commits