1. 18 Jul, 2019 1 commit
  2. 16 Jul, 2019 3 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
      2fa920c0
    • Cristian Adam (ooo until 17th of October)'s avatar
      find_package: Fix NO_MODULE under CMAKE_FIND_PACKAGE_PREFER_CONFIG · f2edccea
      The module mode fallback added by commit 22e65d10 (find_package: Fixed
      CMAKE_FIND_PACKAGE_PREFER_CONFIG Module fallback, 2019-06-13,
      v3.15.0-rc2~6^2) should not be used unless the `find_package` call
      allows module mode.  Doing so can lead to infinite recursion if a find
      module tries to call config mode with `find_package(...  NO_MODULE)`.
      Fix the logic and add a test case.
      
      Fixes: #19478
      f2edccea
    • 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>
      0ba5891e
  3. 15 Jul, 2019 3 commits
    • Brad King's avatar
      Tests: Drop RunCMake workaround for AIX ld warnings about GNU atexit · c2c3d225
      Brad King authored
      Drop the filtering added by commit e22c45d4 (Tests: Teach RunCMake to
      ignore AIX ld warnings about GNU atexit, 2018-02-28, v3.12.0-rc1~419^2~6).
      It is no longer needed now that we compute our own exports on AIX and
      do not get these warnings when using shared libraries.
      c2c3d225
    • Brad King's avatar
      AIX: Explicitly compute executable exports for both XL and GNU · 9f5c2040
      Brad King authored
      On AIX, symbols in executables must be exported in order to be visible
      to modules (plugins) they load via `dlopen`.  Prior to policy `CMP0065`,
      CMake linked all executables with flags to export symbols, but the NEW
      behavior for that policy is to do so only for executables that have the
      `ENABLE_EXPORTS` target property set.  In both cases, CMake has always
      used the AIX linker option `-bexpall` option to export symbols from
      executables.
      
      This has worked fairly well with the XL compiler, but with the GNU
      compiler it works only for C ABI symbols.  The reason is that `-bexpall`
      does not export symbols starting in `_` but the GNU C++ ABI mangles all
      symbols with a leading `_`.  Therefore we have only supported C ABI
      plugins with the GNU compiler on AIX.  Some projects have tried to work
      around this by replacing `-bexpall` with `-bexpfull`, but the latter
      often exports symbols that we do not want exported.
      
      Avoid using `-bexpall` for executables by instead using by our own
      internal `ExportImportList` script to compute symbol export lists from
      the object files to be linked into an executable.  Pass the explicitly
      computed export list to the AIX linker's `-bE:...` option.  We already
      do this for shared object exports.
      
      Issue: #19163
      9f5c2040
    • Brad King's avatar
      5f846698
  4. 14 Jul, 2019 2 commits
  5. 11 Jul, 2019 2 commits
  6. 10 Jul, 2019 1 commit
    • Brad King's avatar
      IWYU: Fix handling of <memory> standard header · 71fbebd1
      Brad King authored
      An old workaround for `std::allocator_traits<>::value_type` lints from
      IWYU on `std::vector<>` usage breaks IWYU's handling of `<memory>`.
      Convert the workaround to use the same approach we already use for a
      workaround of `std::__decay_and_strip<>::::__type` lints.  Then update
      the `<memory>` inclusions to follow the now-correct IWYU lints.
      71fbebd1
  7. 09 Jul, 2019 5 commits
  8. 05 Jul, 2019 3 commits
  9. 04 Jul, 2019 1 commit
  10. 03 Jul, 2019 2 commits
  11. 01 Jul, 2019 3 commits
    • Brad King's avatar
      Add deprecation warnings for policies CMP0067 and below · cf821ff3
      Brad King authored
      The OLD behaviors of all policies are deprecated, but only by
      documentation.  Add an explicit deprecation diagnostic for policies
      introduced in CMake 3.8 and below to encourage projects to port away
      from setting policies to OLD.
      cf821ff3
    • Sebastian Holtermann's avatar
      Tests: Autogen: Use valid rcc compression levels · 1a2d6bde
      Sebastian Holtermann authored
      Avoid the invalid compression level 0 when invoking rcc.
      It let's rcc fail with an error since Qt 5.13.
      1a2d6bde
    • Robert Maynard's avatar
      CUDA: Do not device link if CUDA is not an enabled language · a4d502a5
      Robert Maynard authored
      Checks added in commit 81b4d10d (CUDA: More exhaustive checks to
      determine when to do device linking, 2019-05-09, v3.15.0-rc1~82^2)
      assumed that CUDA properties would be set only if CUDA is enabled.
      
      We cannot do a device link step if we do not have the CUDA language
      enabled.  This was discovered as some projects unconditionally set CUDA
      properties such as `CUDA_RESOLVE_DEVICE_SYMBOLS` even when the CUDA
      language has not been enabled.
      
      Fixes: #19432
      a4d502a5
  12. 30 Jun, 2019 1 commit
  13. 27 Jun, 2019 1 commit
  14. 26 Jun, 2019 3 commits
  15. 25 Jun, 2019 3 commits
  16. 24 Jun, 2019 3 commits
  17. 21 Jun, 2019 2 commits
  18. 19 Jun, 2019 1 commit