1. 17 Feb, 2022 10 commits
  2. 16 Feb, 2022 27 commits
  3. 15 Feb, 2022 3 commits
    • Brad King's avatar
      target_link_libraries: Improve tolerance of unquoted generator expressions · c1e812ad
      Brad King authored
      Prior to commit 1d709ea2 (cmGeneratorTarget: Propagate backtraces from
      INTERFACE_LINK_LIBRARIES, 2021-12-15, v3.23.0-rc1~228^2), the value of
      `INTERFACE_LINK_LIBRARIES` was a single string.  If an unquoted
      generator expression passed to `target_link_libraries` contained `;` and
      became multiple arguments, they would all accumulate as a single
      `;`-separated list in the value of `INTERFACE_LINK_LIBRARIES`.  Since
      that commit, each argument to `target_link_libraries` is placed in
      `INTERFACE_LINK_LIBRARIES` as a separate entry, as has long been the
      case for `LINK_LIBRARIES`. That behavior change broke projects that were
      accidentally relying on accumulation in `INTERFACE_LINK_LIBRARIES` to
      produce complete generator expressions containing `;`.
      
      Teach `target_link_libraries` to accumulate consecutive non-keyword
      arguments into a single entry before placing them in `LINK_LIBRARIES` or
      `INTERFACE_LINK_LIBRARIES`.  For example, treat `a b c` as if they were
      written as `"a;b;c"`.  This restores the previously accidental support
      for unquoted generator expressions in `INTERFACE_LINK_LIBRARIES`, and
      also enables it for `LINK_LIBRARIES`.
      
      For now, do not drop the `target_link_libraries` documentation that
      recommends quoting generator expressions.  Quoting is still important to
      populate `LINK_LIBRARIES` in CMake 3.22 and below, and is also good
      practice to keep generator expressions whole.
      
      Fixes: #23203
      c1e812ad
    • Brad King's avatar
    • Brad King's avatar
      target_link_libraries: Remove likely-broken ancient compatibility check · 42590df9
      Brad King authored
      Since commit daa6d2bc (ENH: updated handling of debug and optimized
      target link libraries, 2006-11-29, v2.6.0~2471) the ancient
      `<lib>_LINK_TYPE` compatibility lookup was done using the name of the
      dependent target for which `target_link_libraries` is called, rather
      than the name of the library dependency being considered.  This code
      probably does nothing.  Remove it.
      42590df9