1. 20 Jan, 2011 1 commit
    • Brad King's avatar
      Modules: Include builtin FindPackageHandleStandardArgs directly · c4275592
      Brad King authored
      The FindPackageHandleStandardArgs module was originally created outside
      of CMake.  It was added for CMake 2.6.0 by commit e118a627 (add a macro
      FIND_PACKAGE_HANDLE_STANDARD_ARGS..., 2007-07-18).  However, it also
      proliferated into a number of other projects that at the time required
      only CMake 2.4 and thus could not depend on CMake to provide the module.
      CMake's own find modules started using the module in commit b5f656e0
      (use the new FIND_PACKAGE_HANDLE_STANDARD_ARGS in some of the FindXXX
      modules..., 2007-07-18).
      Then commit d358cf5c (add 2nd, more powerful mode to
      find_package_handle_standard_args, 2010-07-29) added a new feature to
      the interface of the module that was fully optional and backward
      compatible with all existing users of the module.  Later commit 5f183caa
      (FindZLIB: use the FPHSA version mode, 2010-08-04) and others shortly
      thereafter started using the new interface in CMake's own find modules.
      This change was also backward compatible because it was only an
      implementation detail within each module.
      Unforutnately these changes introduced a problem for projects that still
      have an old copy of FindPackageHandleStandardArgs in CMAKE_MODULE_PATH.
      When any such project uses one of CMake's builtin find modules the line
      loads the copy from the project which does not have the new interface!
      Then the including find module tries to use the new interface with the
      old module and fails.
      Whether this breakage can be considered a backward incompatible change
      in CMake is debatable.  The situation is analagous to copying a standard
      library header from one version of a compiler into a project and then
      observing problems when the next version of the compiler reports errors
      in its other headers that depend on its new version of the original
      header.  Nevertheless it is a change to CMake that causes problems for
      projects that worked with previous versions.
      This problem was discovered during the 2.8.3 release candidate cycle.
      It is an instance of a more general problem with projects that provide
      their own versions of CMake modules when other CMake modules depend on
      them.  At the time we resolved this instance of the problem with commit
      b0118402 (Use absolute path to FindPackageHandleStandardArgs.cmake
      everywhere, 2010-09-28) for the 2.8.3 release.
      In order to address the more general problem we introduced policy
      CMP0017 in commit db44848f (Prefer files from CMAKE_ROOT when including
      from CMAKE_ROOT, 2010-11-17).  That change was followed by commit
      ce28737c (Remove usage of CMAKE_CURRENT_LIST_DIR now that we have
      CMP0017, 2010-12-20) which reverted the original workaround in favor of
      using the policy.  However, existing project releases do not set the
      policy behavior to NEW and therefore still exhibit the problem.
      We introduced in commit a364daf1 (Allow users to specify defaults for
      unset policies, 2011-01-03) an option for users to build existing
      projects by adding -DCMAKE_POLICY_DEFAULT_CMP0017=NEW to the command
      line.  Unfortunately this solution still does not allow such projects to
      build out of the box, and there is no good way to suggest the use of the
      new option.
      The only remaining solution to keep existing projects that exhibit this
      problem building is to restore the change originally made in commit
      b0118402 (Use absolute path to FindPackageHandleStandardArgs.cmake
      everywhere, 2010-09-28).  This also avoids policy CMP0017 warnings for
      this particular instance of the problem the policy addresses.
  2. 17 Jan, 2011 7 commits
  3. 14 Jan, 2011 2 commits
  4. 13 Jan, 2011 2 commits
    • David Cole's avatar
      David Cole authored
      The parent commit added a warning message whenever a required file
      does not exist.
      As it turns out, the "required" files never exist when built with
      Visual Studio Express editions. Add a variable to suppress these
      warning messages because only packagers or naive includers of
      this file will care to see such warning messages.
      We want to warn about this condition by default so that people who
      are using InstallRequiredSystemLibraries without understanding it
      fully will have a chance of understanding why it's not working in
      the event of missing required files.
      But we also want to give projects the ability to suppress this warning
      (by "project's choice default") so that they can encourage users who
      are restricted to using an Express edition to build their project.
      Packagers should explicitly use...
      ...when building releases. That way, their release build process will warn
      them about any missing files, but only if their project CMakeLists files
      use a construct similar to CMake's:
    • David Cole's avatar
      VS10: Fix problems with InstallRequiredSystemLibraries. · fc144924
      David Cole authored
      Thanks to "J Decker" on the CMake mailing list for pointing out
      that one of the MSVC10_CRT_DIR settings was using "VC90" instead
      of "VC100".
      After fixing that, I added the code to generate a CMake warning
      if one of the files we think is "required" does not exist.
      Then, with VS10, there were several other problems that the
      warning revealed:
       - MSVC10_REDIST_DIR needed more PATHS to be found correctly
       - the 64-bit directory is named "x64" now, not "amd64" as in
         previous VS versions
       - manifest files no longer exist as separate files in the
         redist subdirectories (they must be built-in as resources
         to the dlls...?)
  5. 12 Jan, 2011 1 commit
  6. 11 Jan, 2011 1 commit
    • David Cole's avatar
      CPack: Add CPACK_NSIS_INSTALL_ROOT variable (#9148) · 5a9e8e70
      David Cole authored and Brad King's avatar Brad King committed
      Control the root directory of the default directory presented to
      the end user of an NSIS installer by a CPack variable.
      Previously, the value used in the NSIS script was $PROGRAMFILES,
      which is equivalent to the "ProgramFiles" environment variable.
      That default value is still the same, but now a project may
      override the value by setting this new variable.
  7. 10 Jan, 2011 2 commits
  8. 07 Jan, 2011 1 commit
  9. 06 Jan, 2011 7 commits
    • David Cole's avatar
      ExternalProject: Avoid bleed-through output when logging. · 44aff73d
      David Cole authored
      Unset VS_UNICODE_OUTPUT when executing a command whose output
      is being logged to a file. Previously, running Microsoft tools
      in sub-processes of Visual Studio would send their output to
      the Visual Studio output pipe named by this environment variable.
      Unsetting it forces the output back to the normal stdout and stderr
      channels where cmake can intercept it and direct it to the
      appropriate log files.
    • Mike McQuaid's avatar
      Add CPack NSIS MUI_FINISHPAGE_RUN support (#11144) · bee514c3
      Mike McQuaid authored
      MUI_FINISHPAGE_RUN is frequently used with NSIS and provides a checkbox
      on the finish page of an installer which specifies whether the specified
      executable should be run when the installer exits. This commit adds support
      for this setting in CPack.
    • Mike McQuaid's avatar
      Add CPACK_NSIS_EXECUTABLES_DIRECTORY (#7828) · 702c8f8b
      Mike McQuaid authored
      NSIS installers default to assuming the executables exist in a
      directory named "bin" under the installation directory. As this
      isn't usual for Windows programs, the addition of this variable
      allows the customization of this directory and links still to be
      created correctly.
    • Mike McQuaid's avatar
      InstallRequiredSystemLibraries debug-only (#11141) · 753b429e
      Mike McQuaid authored
      Add support to InstallRequiredSystemLibraries to only install
      debug libraries when both debug and release versions are available.
      This is as if you are building a debug package then only the debug
      versions are needed but not the release.
    • Mike McQuaid's avatar
      Add variable for InstallRequiredSystemLibraries dir (#11140) · 492cd84f
      Mike McQuaid authored
      InstallRequiredSystemLibraries currently defaults to installing to
      bin on WIN32 and lib otherwise. This patch allows you to configure
      this by using the variable CMAKE_INSTALL_SYSTEM_RUNTIME_DESTINATION.
      It also switches the logic to use a single INSTALL(PROGRAMS) command
      rather than two deprecated uses of the INSTALL_PROGRAMS command.
    • Mike McQuaid's avatar
      Fix incorrect variable documentation (#11127) · dd5c592c
      Mike McQuaid authored
      In InstallRequiredSystemLibraries the documentation details the
      variable CMAKE_SKIP_INSTALL_RULES to skip installation. This
      actually doesn't do anything, the variable required is named
      CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_SKIP. This commit amends the
      documentation to point to the correct variable.
    • David Cole's avatar
      Add PATH_SUFFIXES for finding git. · ed2b314e
      David Cole authored
      This commit makes it automatic to find msysGit installed
      in its default locations on Windows.
  10. 04 Jan, 2011 1 commit
  11. 03 Jan, 2011 1 commit
  12. 01 Jan, 2011 1 commit
  13. 29 Dec, 2010 1 commit
    • Brad King's avatar
      Fix constness in compiler id detection · dbc79bd8
      Brad King authored
      Since commit 70c2dc8a (Make compiler id detection more robust,
      2008-03-10) we store compiler identification strings in test binaries
      using the form
        char* info = "info";
      Use the const-correct
        char const* info = "info";
      form instead.  This allows the C++ compiler identification to work with
      "-Werror -Wall" or equivalent flags if the compiler would warn about
      const-to-non-const conversion.
  14. 28 Dec, 2010 1 commit
    • Wojciech Migda's avatar
      Recognize the Texas Instruments DSP compiler (#11645) · f1392dc9
      Wojciech Migda authored and Brad King's avatar Brad King committed
      The TI DSP compiler predefines "__TI_COMPILER_VERSION__".  Use this to
      identify the C and C++ compilers.  For assembler language the C compiler
      executable is used:
        $ cl6x -h
        TMS320C6x C/C++ Compiler v6.1.11
        Tools Copyright (c) 1996-2009 Texas Instruments Incorporated
      Use this command-line option and output to recognize the assembler.
  15. 27 Dec, 2010 5 commits
  16. 23 Dec, 2010 3 commits
  17. 22 Dec, 2010 1 commit
    • Brad King's avatar
      Pass Mac linker flag through all compilers with -Wl, · e498527f
      Brad King authored
      The Mac linker defines flag -headerpad_max_install_names but not all
      front-ends recognize the flag and pass it through (many did in the past,
      such as the Apple port of GCC).  Use the -Wl, option prefix to tell
      front-ends to pass it through without trying to interpret it.
  18. 17 Dec, 2010 2 commits
    • Brad King's avatar
      Cygwin: Do not define 'WIN32' (#10122) · 85c0a69a
      Brad King authored
      One of Cygwin's goals is to build projects using the POSIX API with no
      Windows awareness.  Many CMake-built projects have been written to test
      for UNIX and WIN32 but not CYGWIN.  The preferred behavior under Cygwin
      in such projects is to take the UNIX path but not the WIN32 path.
      Unfortunately this change is BACKWARDS INCOMPATIBLE for Cygwin-aware
      CMake projects!  Some projects that previously built under Cygwin and
      are Cygwin-aware when they test for WIN32 may now behave differently.
      Eventually these projects will need to be updated, but to help users
      build them in the meantime we print a warning about the change in
      behavior.  Furthermore, one may set CMAKE_LEGACY_CYGWIN_WIN32 to request
      old behavior during the transition.
      Normally we avoid backwards incompatible changes, but we make an
      exception in this case for a few reasons:
      (1) This behavior is preferred by Cygwin's design goals.
      (2) A warning provides a clear path forward for everyone who may see
      incompatible behavior, and CMAKE_LEGACY_CYGWIN_WIN32 provides a
      compatibility option.  The warning and compatibility option both
      disappear when the minimum required version of CMake in a project is
      sufficiently new, so this issue will simply go away over time as
      projects are updated to account for the change.
      (3) The fixes required to update projects are fairly insignificant.
      Furthermore, the Cygwin distribution has no releases itself so project
      versions that predate said fixes tend to be difficult to build anyway.
      (4) This change enables many CMake-built projects that did not
      previously build under Cygwin to work out-of-the-box.  From bug #10122:
        "I have built over 120 different source packages with (my patched)
         CMake, including most of KDE4, and have found that NOT defining
         WIN32 on Cygwin is much more accurate." -- Yaakov Selkowitz
      A fully compatible change would require patches on top of these project
      releases for Cygwin even though they otherwise need not be aware of it.
      (5) Yaakov has been maintaining a fork of CMake with this change for the
      Cygwin Ports distribution.  It works well in practice.  By accepting the
      change in upstream CMake we avoid confusion between the versions.
      CMake itself builds without WIN32 defined on Cygwin.  Simply disable
      CMAKE_LEGACY_CYGWIN_WIN32 explicitly in our own CMakeLists.txt file.
    • Brad King's avatar
      Declare min CMake version in --system-information project · a6cb1d46
      Brad King authored
      The --system-information flag's project triggered a CMP0000 warning
      because the CMakeLists.txt it generates needs cmake_minimum_required.