1. 10 Feb, 2021 1 commit
  2. 08 Feb, 2021 1 commit
  3. 07 Feb, 2021 1 commit
  4. 05 Feb, 2021 1 commit
  5. 04 Feb, 2021 3 commits
    • Craig Scott's avatar
      FetchContent: Invoke steps directly and avoid a separate sub-build · 17e5516e
      Craig Scott authored
      The cost of setting up and executing a separate sub-build to do the
      download, update and patch steps required for FetchContent population
      can be significant with some platforms and CMake generators. Avoid the
      sub-build altogether by invoking the step scripts directly.
      Previously, if no generator was set (e.g. population was being done in
      script mode), a generator needed to be available on the default PATH.
      Since we no longer use a sub-build, this restriction is also now gone.
      Fixes: #21703
    • Craig Scott's avatar
      ExternalProject: Refactor pre-configure steps to support no-target uses · 4f3d1abb
      Craig Scott authored
      The mkdir, download, update and patch steps are used by
      FetchContent during the configure phase of the main build. Because
      these steps need a target, this has so far required a sub-build to be
      set up. The changes here factor out the preparation of the scripts
      from the creation of the targets, allowing future work to leverage these
      steps without a sub-build (see #21703).
      As part of the refactoring, some rationalisation of the stamp files,
      repository info files and script names was done to make things more
      consistent between download methods and step implementations.
      Every download method now records its own specific repository info
      in a file and that file is a dependency of the download step. The source
      directory is also written to that file, so if the SOURCE_DIR changes, the
      download will be retriggered (the existing implementation fails in this
      scenario). Each download method now also has just one driver script
      that implements the whole step (it may pull in other scripts to do its
      task though). The patch step gained support for USES_TERMINAL as
      a result of generalising the implementation for custom commands.
      Fixes: #21748
    • Brad King's avatar
  6. 03 Feb, 2021 2 commits
  7. 02 Feb, 2021 1 commit
  8. 01 Feb, 2021 1 commit
  9. 31 Jan, 2021 1 commit
  10. 29 Jan, 2021 1 commit
  11. 27 Jan, 2021 1 commit
  12. 26 Jan, 2021 3 commits
  13. 25 Jan, 2021 1 commit
  14. 22 Jan, 2021 1 commit
    • Deniz Bahadir's avatar
      CPackDeb: dpkg-shlibdeps now supports searching for private shared libs · d586a4ad
      Deniz Bahadir authored
      can be set to a list of directories. If `CPACK_DEBIAN_PACKAGE_SHLIBDEPS`
      or `CPACK_DEBIAN_<component>_PACKAGE_SHLIBDEPS` are set to `ON` these
      directories will be searched by `dpkg-shlibdeps` in order to find
      private shared library dependencies of the libraries/executables that
      shall be packed.
  15. 21 Jan, 2021 1 commit
  16. 20 Jan, 2021 1 commit
    • jonathan molinatto's avatar
      VS: Generalize Win10 max SDK version to all VS generators · 1e67482d
      jonathan molinatto authored
      CMake 3.19 by commit ba497111 (VS: Add option for custom Win10 SDK
      version maximum, 2020-08-20, v3.19.0-rc1~262^2) was documented as if it
      worked for all generators but implemented only to override CMake's
      builtin default for the VS 2015 max SDK version.  Generalize the
      variable to set a custom max SDK version for later VS versions too.
      Fixes: #21720
  17. 15 Jan, 2021 1 commit
  18. 13 Jan, 2021 1 commit
  19. 12 Jan, 2021 1 commit
  20. 11 Jan, 2021 1 commit
  21. 07 Jan, 2021 1 commit
    • Brad King's avatar
      ci: build separate macOS packages for macOS 10.13+ and macOS 10.10+ · 6410425e
      Brad King authored
      In order to support modern macOS features like Dark Mode, we need to use
      Qt 5.15, which requires macOS 10.13.  However, we still want to support
      macOS 10.10 as well, for which we need to use Qt 5.9.  Build separate
      macOS packages for these use cases.
      Fixes: #21606
      Issue: #20825
  22. 05 Jan, 2021 1 commit
  23. 29 Dec, 2020 1 commit
  24. 23 Dec, 2020 2 commits
  25. 22 Dec, 2020 1 commit
  26. 21 Dec, 2020 1 commit
  27. 19 Dec, 2020 1 commit
  28. 16 Dec, 2020 2 commits
  29. 15 Dec, 2020 2 commits
  30. 14 Dec, 2020 1 commit
    • Robert Maynard's avatar
      ISPC: Generated Headers suffix configurable with a better default · c9a50f35
      Robert Maynard authored
      The target property `ISPC_HEADER_SUFFIX` and associated global
      variable now can control the suffix used when generating the
      C/C++ interoperability ISPC headers.
      In addition the default suffix is now "_ispc.h" which matches the
      common convention that the ISPC compiler team uses and recommends.
  31. 11 Dec, 2020 1 commit
  32. 10 Dec, 2020 1 commit
    • Brad King's avatar
      macOS: Offer control over host architecture on Apple Silicon hosts · 5f882f6c
      Brad King authored
      Since commit b6c60f14 (macOS: Default to arm64 architecture on Apple
      Silicon hosts, 2020-09-28, v3.19.0-rc1~63^2) we use `sysctl` to detect
      that we are running on Apple Silicon in a way that pierces Rosetta.
      This always sets `CMAKE_HOST_SYSTEM_PROCESSOR` to be `arm64` on such
      hosts.  However, macOS offers strong support for running processes under
      an emulated `x86_64` architecture.
      Teach CMake to select either `arm64` or `x86_64` as the host
      architecture on Apple Silicon based on the architecture of its own
      process.  When CMake is built as a universal binary, macOS will select
      whichever slice (architecture) is appropriate under the user's shell,
      and `CMAKE_HOST_SYSTEM_PROCESSOR` will match.
      Also offer a `CMAKE_APPLE_SILICON_PROCESSOR` variable and environment
      variable to provide users with explicit control over the host
      architecture selection regardless of CMake's own architecture.
      Finally, if `CMAKE_OSX_ARCHITECTURES` is not set, pas...