1. 29 Jul, 2021 1 commit
    • Brad King's avatar
      VS: Fix assertion failure on INCLUDE_DIRECTORIES in INTERFACE libraries · 53aabe98
      Brad King authored
      Since commit 43919131 (Add INTERFACE libraries to generated
      buildsystem if they have SOURCES, 2020-07-20, v3.19.0-rc1~346^2~1), the
      VS generator may process INTERFACE libraries.  Avoid code paths in the
      generator that process include directories because they should not be
      used by INTERFACE libraries since they do not compile anything.
      
      Fixes: #22494
      53aabe98
  2. 07 Aug, 2020 1 commit
    • Brad King's avatar
      Add INTERFACE libraries to generated buildsystem if they have SOURCES · 43919131
      Brad King authored
      INTERFACE libraries were created with the intention of collecting usage
      requirements for use by other targets via `target_link_libraries`.
      Therefore they were not allowed to have SOURCES and were not included in
      the generated buildsystem.  In practice, this has become limiting:
      
      * Header-only libraries do have sources, they just do not compile.
        Developers should be able to edit those sources (the header files)
        in their IDE.
      
      * Header-only libraries may need to generate some of their header
        files via custom commands.
      
      Some projects work around these limitations by pairing each interface
      library with an `add_custom_target` that makes the header files and
      custom commands appear in the generated buildsystem and in IDEs.
      
      Lift such limitations by allowing INTERFACE libraries to have SOURCES.
      For those with sources, add a corresponding build target to the
      generated buildsystem.
      
      Fixes: #19145
      43919131
  3. 03 Aug, 2020 1 commit
    • Brad King's avatar
      Remove filtering of allowed INTERFACE library properties · afb99870
      Brad King authored
      Previously we disallowed use of arbitrary properties on INTERFACE
      libraries.  The goal was to future-proof projects using them by not
      allowing properties to be set that may affect their future inclusion in
      the generated buildsystem.  In order to prepare to actually include
      INTERFACE libraries in the generated buildsystem, drop the filter and
      allow arbitrary properties to be set.
      
      Issue: #19145
      afb99870
  4. 22 Jul, 2020 1 commit
  5. 09 Nov, 2016 1 commit
    • Brad King's avatar
      Allow imported INTERFACE libraries to specify a link library name · 09cda9d5
      Brad King authored
      Add an `IMPORTED_LIBNAME[_<CONFIG>]` target property to specify a library
      name to be placed on the link line in place of an interface library
      since it has no library file of its own.  Restrict use of the property
      to imported `INTERFACE` libraries.
      
      This will be particularly useful for find modules that need to provide
      imported libraries from system SDKs where the full path to the library
      file is not known.  Now such find modules will be able to provide an
      imported interface library and set `IMPORTED_LIBNAME` to refer to the
      SDK library by name.
      
      Issue: #15267
      09cda9d5
  6. 27 Mar, 2015 1 commit
    • Brad King's avatar
      Allow add_dependencies() on INTERFACE libraries (#15414) · ac14cbf0
      Brad King authored
      Revert commit v3.0.0-rc1~175^2~20 (add_dependencies: Disallow use with
      INTERFACE_LIBRARY, 2013-12-25).  Teach our dependency analysis to
      transitively follow INTERFACE target utility dependencies as was done or
      IMPORTED targets in commit v2.8.6~127^2~1 (Allow add_dependencies() on
      imported targets, 2010-11-19).  Extend the InterfaceLibrary test with a
      case to cover header generation for a header-only INTERFACE library via
      a custom target.
      ac14cbf0
  7. 19 Mar, 2014 1 commit
  8. 07 Feb, 2014 1 commit
  9. 06 Jan, 2014 1 commit
  10. 04 Jan, 2014 1 commit
  11. 09 Dec, 2013 1 commit
    • Stephen Kelly's avatar
      Don't search for IMPORTED_LOCATION of INTERFACE_LIBRARY (14636) · 3b8e56a5
      Stephen Kelly authored
      The INTERFACE_LIBRARY type does not have any LOCATION at all, so
      return early from GetMappedConfig. GetMappedConfig is called from
      two locations, one of which already pre-checks the INTERFACE_LIBRARY
      case. Remove that pre-check and handle that case inside the method
      instead.
      3b8e56a5
  12. 25 Nov, 2013 1 commit
  13. 12 Nov, 2013 1 commit
  14. 07 Oct, 2013 1 commit
    • Stephen Kelly's avatar
      Add the INTERFACE_LIBRARY target type. · fe732264
      Stephen Kelly authored and Brad King's avatar Brad King committed
      This target type only contains INTERFACE_* properties, so it can be
      used as a structural node. The target-specific commands enforce
      that they may only be used with the INTERFACE keyword when used
      with INTERFACE_LIBRARY targets. The old-style target properties
      matching LINK_INTERFACE_LIBRARIES_<CONFIG> are always ignored for
      this target type.
      
      The name of the INTERFACE_LIBRARY must match a validity generator
      expression. The validity is similar to that of an ALIAS target,
      but with the additional restriction that it may not contain
      double colons. Double colons will carry the meaning of IMPORTED
      or ALIAS targets in CMake 2.8.13.
      
      An ALIAS target may be created for an INTERFACE library.
      
      At this point it can not be exported and does not appear in the
      buildsystem and project files are not created for them. That may
      be added as a feature in a later commit.
      
      The generators need some changes to handle the INTERFACE_LIBRARY
      targets returned by cmComputeLinkInterface::GetItems. The Ninja
      generator does not use that API, so it doesn't require changes
      related to that.
      fe732264