1. 30 Jan, 2019 1 commit
    • Brad King's avatar
      Xcode: Fix object library builds with sanitizers enabled · 8a7f93d0
      Brad King authored
      Using `xcodebuild -enableAddressSanitizer YES ...` causes object files
      to be placed in a different directory name.  Xcode provides a
      placeholder for this that we can use in `OTHER_LDFLAGS` to reference
      object files for linking the dependents of object libraries.  However,
      CMake's features for installing and exporting object libraries depend on
      knowing the real path with no placeholders.  For these cases, use the
      default object directory.  Users will then have to choose between
      sanitizers and the installation and export features, but both will work
      individually.
      
      Fixes: #16289
      8a7f93d0
  2. 23 Jan, 2019 1 commit
  3. 22 Jan, 2019 1 commit
  4. 21 Jan, 2019 1 commit
  5. 18 Jan, 2019 1 commit
  6. 17 Jan, 2019 1 commit
  7. 16 Jan, 2019 1 commit
  8. 15 Jan, 2019 1 commit
  9. 20 Nov, 2018 1 commit
  10. 11 Nov, 2018 1 commit
  11. 08 Nov, 2018 1 commit
  12. 06 Nov, 2018 1 commit
  13. 31 Oct, 2018 2 commits
    • Brad King's avatar
      CSharp: Fix regression in VS project type selection for custom target · 1acd1c2b
      Brad King authored
      A target created by `add_custom_target` should always be a `.vcxproj`
      file even if it has `.cs` sources involved in custom commands and such.
      The latter case was broken by refactoring in commit v3.12.0-rc1~160^2~7
      (remove TargetIsCSharpOnly() and use methods from cmGeneratorTarget,
      2018-03-19).  The reason is that the `HasLanguage` method added by
      commit v3.12.0-rc1~239^2~6 (cmGeneratorTarget: add HasLanguage() as
      wrapper for GetLanguages(), 2018-03-19) does not check the target type
      and so is not a suitable check for deciding the project file extension.
      
      The `HasLanguage` method was an attempt at an abstraction that turns
      out not to work very well.  Replace it with a dedicated `IsCSharpOnly`
      method that considers the target type, sources, and non-transitive
      `LINKER_LANGUAGE`.
      
      Fixes: #18515
      1acd1c2b
    • Brad King's avatar
      CSharp: Fix regression in VS project type selection for custom target · a56edad6
      Brad King authored
      A target created by `add_custom_target` should always be a `.vcxproj`
      file even if it has `.cs` sources involved in custom commands and such.
      The latter case was broken by refactoring in commit v3.12.0-rc1~160^2~7
      (remove TargetIsCSharpOnly() and use methods from cmGeneratorTarget,
      2018-03-19).  The reason is that the `HasLanguage` method added by
      commit v3.12.0-rc1~239^2~6 (cmGeneratorTarget: add HasLanguage() as
      wrapper for GetLanguages(), 2018-03-19) does not check the target type
      and so is not a suitable check for deciding the project file extension.
      
      The `HasLanguage` method was an attempt at an abstraction that turns
      out not to work very well.  Replace it with a dedicated `IsCSharpOnly`
      method that considers the target type, sources, and non-transitive
      `LINKER_LANGUAGE`.
      
      Fixes: #18515
      a56edad6
  14. 18 Oct, 2018 3 commits
    • Brad King's avatar
      Add generator APIs to get build settings with backtraces · 753ab3c9
      Brad King authored
      In cmGeneratorTarget and cmLocalGenerator we offer several APIs to get
      build settings like include directories, compile definitions, source
      files, etc.  Add corresponding APIs that include backtrace information.
      753ab3c9
    • Brad King's avatar
      add_dependencies: Track backtraces internally · a6e02f88
      Brad King authored
      Record backtraces for "utility" dependencies created by
      `add_dependencies` calls.
      a6e02f88
    • Brad King's avatar
      cmLinkItem: Add backtrace · a093b1a4
      Brad King authored
      Carry a backtrace on every link item, not just link implementation
      items.  For now the non-impl items will still have empty backtraces at
      runtime, but this will allow us to introduce values over time.
      a093b1a4
  15. 16 Oct, 2018 1 commit
  16. 02 Oct, 2018 1 commit
    • Brad King's avatar
      CSharp: Fix regression in VS project type selection · 375b420f
      Brad King authored
      A that target contains only `.cs` sources should be generated as a
      `.csproj` project even if it links to non-CSharp static libraries.
      The latter case was broken by refactoring in commit v3.12.0-rc1~160^2~7
      (remove TargetIsCSharpOnly() and use methods from cmGeneratorTarget,
      2018-03-19).  The reason is that the `HasLanguage` method added by
      commit v3.12.0-rc1~239^2~6 (cmGeneratorTarget: add HasLanguage() as
      wrapper for GetLanguages(), 2018-03-19) enforces its "exclusive" check
      on the combined set of source file languages and the link language.
      To restore the original `TargetIsCSharpOnly` semantics, update
      `HasLanguage` to enforce exclusiveness only on the list of sources.
      
      Fixes: #18239
      375b420f
  17. 25 Sep, 2018 2 commits
  18. 19 Sep, 2018 1 commit
  19. 18 Sep, 2018 1 commit
  20. 12 Sep, 2018 3 commits
    • Brad King's avatar
      target_link_libraries: Allow use with targets in other directories · a1ad0a69
      Brad King authored
      Previously the command did not allow naming targets on the LHS that
      were not created in the calling directory.  Lift this restriction to
      enable more flexible use by projects.
      
      Targets named on the RHS will need to be looked up during generation in
      the scope of the call site rather than the scope of the LHS target.
      Introduce an internal syntax in `[INTERFACE_]LINK_LIBRARIES` properties
      to specify target names that need to be looked up in a directory other
      than that containing the target on which the property is set.  Add
      minimal documentation of the syntax to help users that encounter it.
      
      Unfortunately CMake previously did allow such calls in the case that
      only `INTERFACE` libraries are specified, but those libraries would be
      looked up in the target's directory rather than the caller's.  Add
      policy `CMP0079` to enable the new behavior with new lookup scope in a
      compatible way.
      
      Fixes: #17943
      a1ad0a69
    • Brad King's avatar
    • Brad King's avatar
      Make internal TARGET_PROPERTY generator expressions more robust · 2f708f5d
      Brad King authored
      While collecting usage requirements from the `INTERFACE_*` properties of
      directly linked targets, we internally generate `TARGET_PROPERTY:` and
      `TARGET_OBJECTS:` generator expressions to refer to those properties on
      those targets.  At the point we generate these expressions we already
      have a pointer to an exact `cmGeneratorTarget` instance.
      
      Switch from using the target name in these generator expressions to
      using an internal unique name generated for each `cmGeneratorTarget`
      instance to be referenced.  This avoids depending on the user-facing
      target name to find the same target we already have.
      2f708f5d
  21. 10 Sep, 2018 1 commit
    • Brad King's avatar
      Fix transitive usage requirements through same-name imported targets · f35be599
      Brad King authored
      If two imported targets in different directories have the same name we
      should still be able to propagate transitive usage requirements from
      both.  Fix the DAG checker to work with target pointers instead of
      target names since the pointers will not be duplicated even if the names
      are.
      
      Fixes: #18345
      f35be599
  22. 07 Sep, 2018 2 commits
    • Brad King's avatar
      Fix dependency propagation through same-name imported targets · bea390e9
      Brad King authored
      If two imported targets in different directories have the same name we
      should still be able to propagate transitive link dependencies from
      both.  Fix the target and link dependency analyzers to de-duplicate
      targets using target pointers rather than target names since the
      pointers will not be duplicated even if the names are.
      
      Issue: #18345
      bea390e9
    • Brad King's avatar
      cmLinkItem: Convert to a "sum type" over a string and target pointer · fc7e4d1e
      Brad King authored
      Avoid exposing the item name implicitly as std::string.  When the item
      is a target, avoid storing a second copy of its name.
      
      Most link item construction is paired with calls to `FindTargetToLink`
      to get the possible target pointer.  Rename these methods to
      `ResolveLinkItem` and refactor them to construct the entire item.
      fc7e4d1e
  23. 05 Sep, 2018 1 commit
  24. 27 Aug, 2018 1 commit
  25. 15 Aug, 2018 1 commit
  26. 09 Aug, 2018 1 commit
  27. 07 Aug, 2018 1 commit
  28. 11 Jul, 2018 1 commit
  29. 02 Jul, 2018 1 commit
  30. 27 Jun, 2018 2 commits
  31. 06 Jun, 2018 2 commits