1. 07 Aug, 2019 1 commit
  2. 06 Aug, 2019 1 commit
  3. 05 Aug, 2019 2 commits
  4. 26 Jul, 2019 4 commits
    • Brad King's avatar
    • Brad King's avatar
      Android: Use unified toolchain in NDK r19+ · 97bca2f9
      Brad King authored
      The NDK build system now uses only a single toolchain in
      Its compilers are always `bin/{clang,clang++}` and its binutils are
      always `bin/<triple>-*`.  It is a standalone toolchain:
      * The Anrdoid API level is specified at the end of `--target=`.
      * The standard library may be specified via `-stdlib=`.
      * No need to pass system includes or libraries explicitly.
      * No need to pass `--sysroot` or `-gcc-toolchain`.
      Teach CMake to recognize NDK versions that have a unified
      toolchain with its own sysroot and use the above approach.
      Fixes: #18739
    • Brad King's avatar
      CMakeVersion: Use '-rc0' version suffix on release branches prior to rc1 · eb5ea5a5
      Brad King authored
      Revert the change from commit 7b354baa (CMakeVersion: Set
      CMake_VERSION_RC to 0 even in non-rc versions, 2019-07-25) and instead
      define a `0` value in `CMake_VERSION_RC` to mean `-rc0`.  This
      distinguishes release branch versions prior to the first release
      candidate from the first release candidate itself.  It also makes room
      for a dedicated "CMake $major.$minor.0-rc1" release commit for `-rc1` as
      we have for later release candidates and final releases.
    • Brad King's avatar
      Help: Add 3.15.1 release notes · 3b113cc1
      Brad King authored
  5. 25 Jul, 2019 4 commits
  6. 24 Jul, 2019 2 commits
  7. 22 Jul, 2019 1 commit
  8. 21 Jul, 2019 1 commit
    • Alex Turbov's avatar
      CPack: Introduce CPACK_INSTALL_SCRIPTS variable · 5f966016
      Alex Turbov authored
      The singular name `CPACK_INSTALL_SCRIPT` has existed but was not linked
      from the CPack documentation.  Also, it supported multiple values and
      should have had a plural name.  Add a plural-named alternative now.
      If both `CPACK_INSTALL_SCRIPTS` and `CPACK_INSTALL_SCRIPT` are set then
      ignore the latter with a warning.
      Signed-off-by: Alex Turbov's avatarAlex Turbov <i.zaufi@gmail.com>
  9. 20 Jul, 2019 1 commit
  10. 19 Jul, 2019 4 commits
  11. 18 Jul, 2019 1 commit
  12. 17 Jul, 2019 3 commits
    • Saleem Abdulrasool's avatar
      Swift: support multithreaded compilation · 47e28cbe
      Saleem Abdulrasool authored
      Query the number of logical CPUs available to enable parallel
      compilation for Swift.
    • Brad King's avatar
      AIX: Do not enable runtime linking by default anymore · 3fb3157d
      Brad King authored
      We've long created shared objects on AIX using the linker's `-G` option
      (also offered by the XL front-end).  The `-G` option implies `-brtl` and
      enables runtime linking.  This has been largely unnecessary because we
      provide all dependencies on the link line and both XL and GNU compilers
      offer builtin behavior to export symbols.  Since commit 0f150b69 (AIX:
      Explicitly compute shared object exports for both XL and GNU,
      2019-07-11) we compute exports explicitly and consistently.
      Therefore runtime linking is no longer necessary for shared objects.
      We've also long created executables on AIX using the linker's `-brtl`
      option to enable runtime linking in case they load plugins at runtime.
      Since commit 9f5c2040 (AIX: Explicitly compute executable exports for
      both XL and GNU, 2019-07-12) and commit 2fa920c0 (AIX: Create import
      library for executables with exports, 2019-07-16) we now provide the
      linker enough information to fully resolve symbols in plugins up front.
      Therefore runtime linking is no longer necessary for executables.
      Drop use of `-G` for creating shared objects and use the XL `-qmkshrobj`
      and GCC `-shared` options instead.  Both invoke the linker with the
      `-bM:SRE -bnoentry` options to create a shared object without runtime
      linking enabled.  Also drop use of `-brtl` for creating executables.
      Issue: #19163
    • Craig Scott's avatar
  13. 16 Jul, 2019 4 commits
    • Brad King's avatar
      AIX: Create import library for executables with exports · 2fa920c0
      Brad King authored
      On AIX, plugins meant to be loaded into executables via `dlopen` must be
      linked with access to a list of symbols exported from the executable in
      order to use them (when not using runtime linking).  The AIX linker
      supports specifying this list as an "import file" passed on the command
      line either via the `-bI:...` option or (with a leading `#! .` line) as
      a normal input file like any other library file.
      The linker import file plays the same role on AIX as import libraries do
      on Windows.  Teach CMake to enable its import library abstraction on AIX
      for executables with the `ENABLE_EXPORTS` target property set.  Teach
      our internal `ExportImportList` script to optionally generate a leading
      `#! .` line at the top of the generated export/import list.  Update our
      rule for linking an executable with exports to generate a public-facing
      "import library" implemented as an AIX linker import file.
      With this approach, our existing infrastructure for handling import
      libraries on Windows will now work for AIX linker import files too:
      * Plugins that link to their executable's symbols will be automatically
        linked using the import file on the command line.
      * The executable's import file will be (optionally) installed and
        exported for use in linking externally-built plugins.
      This will allow executables and their plugins to build even if we later
      turn off runtime linking.
      Issue: #19163
    • Brad King's avatar
      Help: Clarify ENABLE_EXPORTS per-platform link behavior · 84ddeb8f
      Brad King authored
      Spell out the behavior on each platform in a bullet list.
    • Brad King's avatar
      Help: Simplify CMAKE_ENABLE_EXPORTS documentation · e29ccfca
      Brad King authored
      In real projects the variable form should rarely be used because the
      decision to export symbols from an executable is very specific.
      Remove its main description, which duplicates the `ENABLE_EXPORTS`
      target property, and simply reference the property instead.
    • Alex Turbov's avatar
      project: Keep leading `0` in PROJECT_VERSION components · 0ba5891e
      Alex Turbov authored
      Introduce CMake policy `CMP0096` to make `project()` keep leading zeros
      in version components.  As a side effect, it now allows really long
      version numbers.
      Fixes: #19421
      Co-Author: Brad King <brad.king@kitware.com>
  14. 12 Jul, 2019 1 commit
  15. 11 Jul, 2019 2 commits
  16. 10 Jul, 2019 1 commit
  17. 09 Jul, 2019 4 commits
  18. 08 Jul, 2019 1 commit
    • Craig Scott's avatar
      Help: Use consistent levels for cmake --loglevel and message() · 14ed40d6
      Craig Scott authored
      The message() command requires uppercase log levels. Even
      though the cmake --loglevel option is not case sensitive, show
      the supported values as uppercase to match the message()
      docs as closely as possible, since they are related to the same
      Also fixes the wrong string being shown for the warning level
      by cmake --help.
  19. 03 Jul, 2019 2 commits