1. 10 Mar, 2015 1 commit
  2. 11 Feb, 2015 2 commits
    • Brad King's avatar
      install: Allow generator expressions in TARGETS DESTINATION (#14317) · f30022eb
      Brad King authored
      This will allow per-config destinations for targets in EXPORT sets.
      Using multiple install(TARGETS) with separate CONFIGURATIONS is
      rejected as a target appearing more than once in an export set.
      Now instead one can write
       install(TARGETS foo EXPORT exp DESTINATION lib/$<CONFIG>)
      to get a single logical membership of the target in the export set
      while still having a per-config destination.
    • Brad King's avatar
      cmInstallGenerator: Move GetDestination to subclasses that need it · f99991db
      Brad King authored
      The method is used only for EXPORT and TARGET install destinations.
      While at it, make it return a std::string by reference instead of a
      "const char*".
  3. 10 Feb, 2015 1 commit
  4. 11 Jan, 2015 1 commit
  5. 15 Dec, 2014 1 commit
    • Brad King's avatar
      install: Allow absolute EXPORT destination with relative targets (#15258) · dd089e08
      Brad King authored
      When install(EXPORT) is given an absolute destination we cannot compute
      the install prefix relative to the installed export file location.
      Previously we disallowed installation of targets in such exports with a
      relative destination, but did not enforce this for target property
      values besides the location of the main target file.  This could lead to
      broken installations when the EXPORT is installed to an absolute path
      but usage requirements are specified relative to the install prefix.
      Since an EXPORT installed to an absolute destination cannot be relocated
      we can just hard-code the value of CMAKE_INSTALL_PREFIX as the base for
      relative paths.  This will allow absolute install(EXPORT) destinations
      to work with relative destinations for targets and usage requirements.
      Extend the ExportImport test with a case covering this behavior.
  6. 29 Nov, 2014 1 commit
    • Stephen Kelly's avatar
      Export: Disallow export of targets with INTERFACE_SOURCES · e1348056
      Stephen Kelly authored
      This can be allowed in the next release, but it needs to have some
      features present and tested such as
      * Ensuring that relative paths do not appear in the generated property.
      * Ensuring that paths to the source or build directories do not appear.
      * Generating a check in the file for CMake 3.1 or later so that the
          resulting property will be consumed.
      * Ensuring that any referenced targets are part of an export set and
          generating a check for them.
      All of these checks are already done for INTERFACE_INCLUDE_DIRECTORIES,
      but it is too late to add them for INTERFACE_SOURCES for CMake 3.1.
      As the checks introduce some new error conditions, it is better to
      disallow exporting fully for this case and introduce proper error
      conditions later instead of policies.
  7. 08 Apr, 2014 1 commit
  8. 11 Mar, 2014 2 commits
  9. 08 Mar, 2014 1 commit
  10. 19 Feb, 2014 1 commit
  11. 11 Feb, 2014 1 commit
  12. 10 Feb, 2014 1 commit
    • Brad King's avatar
      Export: Fix internal CMake version test logic · 9bcc1b21
      Brad King authored
      Fix the internal DEVEL_CMAKE_VERSION macro to use CMake_VERSION_ENCODE
      to compare version component-wise.  Otherwise an old invocation of the
      macro may be tricked into using the current version when the requested
      major version is smaller than the current version but the requested
      minor version is larger.  It should use the requested (old) version in
      that case.
  13. 09 Feb, 2014 1 commit
  14. 04 Jan, 2014 2 commits
    • Stephen Kelly's avatar
      export: Only generate and install configuration files if needed. · af3d3b88
      Stephen Kelly authored
      The modern way to create configuration dependent content is using
      generator expressions in the main export file.  The only non-deprecated
      property still generated in the configuration-specific files are
      INTERFACE_LIBRARY targets have no location, and no need for those
    • Stephen Kelly's avatar
      install: Rename variable referencing cmake version. · a0cacb55
      Stephen Kelly authored
      The next version is 3.0.0, not 2.8.13.
      The version generated in the export file should be updated in
      the release branch in both cmExportInstallFileGenerator and
  15. 19 Dec, 2013 1 commit
    • Stephen Kelly's avatar
      Export: Skip INTERFACE libraries when generating -config files. · b51b6e97
      Stephen Kelly authored
      The properties object has just been created, so is always empty,
      which means the if block is never entered. The following lines do
      not have any effect because an INTERFACE library has no LOCATION.
      At the end, no code is generated for INTERFACE libraries in
      config-specific exported files, so skip them early.
  16. 27 Nov, 2013 1 commit
    • Stephen Kelly's avatar
      QtAutoUic: Add INTERFACE_AUTOUIC_OPTIONS target property. · 98093c45
      Stephen Kelly authored
      Transitively consume the property from linked dependents.
      Implement configuration-specific support by following the pattern
      set out for compile definitions and includes in cmQtAutoGenerators.
      Implement support for origin-tracking with CMAKE_DEBUG_TARGET_PROPERTIES.
      This is motivated by the needs of KDE, which provides a separate
      translation system based on gettext instead of the Qt linguist
      translation system. The Qt uic tool provides command line options
      for configuring the method used to translate text, and to add an
      include directive to the generated file to provide the method.
      Implement the interface to provide the uic options as a usage-requirement
      on the KI18n target, as designed for KDE.
  17. 21 Nov, 2013 1 commit
  18. 10 Oct, 2013 1 commit
  19. 07 Oct, 2013 1 commit
  20. 15 Aug, 2013 1 commit
  21. 24 Jul, 2013 1 commit
  22. 16 Jul, 2013 1 commit
  23. 08 Jul, 2013 1 commit
    • Stephen Kelly's avatar
      Export: Generate INTERFACE_LINK_LIBRARIES property on targets. · 574fec97
      Stephen Kelly authored
      This property is generated only for targets which have recorded
      policy CMP0022 as NEW, and a compatibility mode is added to
      additionally export the old interfaces in that case too.
      If the old interfaces are not exported, the generated export files
      require CMake 2.8.12. Because the unit tests use a version which
      is not yet called 2.8.12, temporarily require a lower version.
  24. 10 Jun, 2013 1 commit
  25. 03 Jun, 2013 2 commits
  26. 23 May, 2013 1 commit
    • Clinton Stimpson's avatar
      Refactor how bundles and frameworks are supported. · 373faae5
      Clinton Stimpson authored
      Make handling of directory separators consistent between
      non-bundle and bundle code.
      Remove xcode specific flag from cmTarget when getting install_name.
      Add (more) consistent convenience functions in cmTarget to get
      directories inside of bundles and frameworks to add files to.
      This refactor also fixes bug #12263 where frameworks
      had the wrong install name when SKIP_BUILD_RPATH.
      Also make install_name for frameworks consistent between Makefile
      and Xcode generator.
  27. 18 May, 2013 1 commit
    • Stephen Kelly's avatar
      Add EXPORT_NAME property. · b5d6f5dd
      Stephen Kelly authored
      This allows for example, the buildsystem to use names like 'boost_any'
      instead of the overly generic 'any', and still be able to generate
      IMPORTED targets called 'boost::any'.
  28. 03 Apr, 2013 1 commit
    • Brad King's avatar
      Handle usr-move without forcing absolute paths (#14041) · 6c613b43
      Brad King authored
      In commit 0c727b90 (install(EXPORT): Force absolute paths for usr-move,
      2013-03-08) and commit d4774140 (configure_package_config_file: force
      absolute paths for usr-move, 2013-01-24) we supported Linux
      distributions implementing the "/usr move" by assuming that installation
      to (/usr)?/lib(64)? represents a non-relocatable system package.
      When cross-compiling one may prepare a package for installation into a
      system location on a target machine but install the package files on the
      *host* machine inside another path for use with CMAKE_FIND_ROOT_PATH.
      In this case the package development files must still be relocatable.
      Handle "/usr move" with a new approach that works with relocatable
      files.  Teach configure_package_config_file and install(EXPORT) to
      generate special logic in a package configuration file or targets file
      for installation under (/usr)?/lib(64)?.  Teach the file to recognize
      when it is loaded through a symlink that refers to the same realpath as
      its original install destination.  In such a case, use the original
      install prefix.  Otherwise, compute the prefix relative to the current
      file location to make it relocatable.
  29. 26 Mar, 2013 1 commit
    • Stephen Kelly's avatar
      install(EXPORT): Ensure clean INTERFACE_INCLUDE_DIRECTORIES · af81a3c3
      Stephen Kelly authored
      Check that source and binary directories are not part of the
      This is limited to directories which do not contain generator
      expressions to evaluate. Such paths can only be checked at time
      of use of the imported target, which will be done in a follow up
  30. 08 Mar, 2013 1 commit
    • Brad King's avatar
      install(EXPORT): Force absolute paths for usr-move · 0c727b90
      Brad King authored
      If the absolute install(EXPORT) destination for the CMAKE_INSTALL_PREFIX
      used during configuration is under (/usr)?/lib(64)? then assume the
      current build is for a system package installation instead of a
      relocatable distribution.  Generate an absolute path for _IMPORT_PREFIX
      in the target exports file instead of generating code to compute the
      value relative to the file location.  This is necessary for
      distributions implementing a move to /usr such as:
       "All files in the /lib directory have been moved to /usr/lib and now
        /lib is a symlink to usr/lib."
      The relative path computation is not reliable because the targets file
      could be installed through cross-prefix a symlink and loaded without it
      or vice versa.
      A similar change was made for package configuration file generation by
      commit d4774140 (configure_package_config_file: force absolute paths for
      usr-move, 2013-01-24).
  31. 27 Jan, 2013 2 commits
  32. 21 Jan, 2013 1 commit
  33. 20 Jan, 2013 1 commit
  34. 15 Jan, 2013 2 commits