summaryrefslogtreecommitdiffstats
path: root/Modules/Platform
Commit message (Collapse)AuthorAgeFilesLines
* Merge topic 'android-ndk-r19-binutils' into release-3.16Brad King2020-02-041-0/+1
|\ | | | | | | | | | | | | e3d3b7ddeb Android: Fix binutils selection with NDK r19+ unified toolchain Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !4318
| * Android: Fix binutils selection with NDK r19+ unified toolchainBrad King2020-02-031-0/+1
| | | | | | | | | | | | | | | | | | | | In commit 97bca2f9fa (Android: Use unified toolchain in NDK r19+, 2019-07-26, v3.16.0-rc1~342^2) we hard-coded use of the unified toolchain for NDK r19+ and skipped most of the old detection logic. However, in that fast path we left out setting `_CMAKE_TOOLCHAIN_PREFIX` for `CMakeFindBinutils` to select the matching binutils. Add it. Fixes: #20038
* | AIX: Restore pre-3.16 undocumented method to suppress exports with XLBrad King2020-01-301-1/+11
|/ | | | | | | | | | | In commit 0f150b69d3 (AIX: Explicitly compute shared object exports for both XL and GNU, 2019-07-11, v3.16.0-rc1~418^2~2) we dropped use of the old `CMAKE_XL_CreateExportList` cache entry for XL exports. However, some people were setting the value to an empty string as a way to disable automatic export of symbols. Restore this behavior when the option is explicitly set to an empty string. Issue: #20290
* Merge topic 'macOS-Xcode-11-frameworks' into release-3.16Brad King2020-01-131-0/+4
|\ | | | | | | | | | | | | | | fcde42751a FindPython: ensure new Xcode framework for Python3 is detected dd7b741b81 macOS: Add support for new Xcode 11 frameworks directory Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !4198
| * macOS: Add support for new Xcode 11 frameworks directoryMarc Chevrier2020-01-101-0/+4
| | | | | | | | Update CMAKE_SYSTEM_FRAMEWORK_PATH with new Xcode 11 frameworks directory
* | GNUtoMS: Add search path for VS 2019 environment scriptsBrad King2020-01-091-1/+1
|/ | | | | | | | Extend the logic from commit abe8a623d9 (GNUtoMS: Add search path for VS 2017 environment scripts, 2017-05-19, v3.8.2~1^2) to consider VS 2019 paths too. Fixes: #20162
* ObjC: Set same settings for all languages supported on DarwinCristian Adam2019-11-071-50/+26
| | | | Fixes: #19928
* PCH: Add support for OBJC/OBJCXX languagesCristian Adam2019-11-031-3/+0
|
* Swift: Honor CMAKE_OSX_SYSROOT on Apple platformsBrad King2019-10-281-0/+1
| | | | | | | | | Pass the value to the Swift compiler driver via `-sdk`. We already do this for C/C++ via `-isysroot`. This fixes command-line builds on macOS 10.15 with Xcode 11 Swift tools. Fixes: #19880
* Apple: Set Clang ASM compiler featuresGregor Jasny2019-10-091-0/+2
| | | | | | | | The same is done for the C and CXX language. This initializes compiler flags like the sysroot path or deployment target. Closes: #19794 Suggested-by: Kyle Fleming
* PCH: Use clang's own pch functionality instead of the GCC emulationCristian Adam2019-10-031-3/+4
| | | | Fixes: #19786
* Languages: Add support for Objective-C++Steve Wilson2019-09-284-3/+18
| | | | | | | | | | | | | | | | | Add entries in Modules and Modules/Platform to support Objective-C++ compiler determination and identification. Add Modules to check Objective-C++ compiler flags, source compilations, program checks, etc... Use OBJCXX as the designator of the language, eg: project(foo OBJCXX) Add various tests for Objective-C++ language features. Add tests to preserve C++ handling of .M and .mm files when Objective-C++ is not a configured language. Co-authored-by: Cristian Adam <cristian.adam@gmail.com>
* Languages: Add support for Objective-CSteve Wilson2019-09-284-1/+18
| | | | | | | | | | | | | | | | | Add entries in Modules and Modules/Platform to support Objective-C compiler determination and identification. Add Modules to check Objective-C compiler flags, source compilations, program checks, etc... Use OBJC as the designator of the language, eg: project(foo OBJC) Add various tests for Objective-C language features. Add tests to preserve C++ handling of .m and .mm files when OBJC is not a configured language. Co-Authored-By: Cristian Adam <cristian.adam@gmail.com>
* Precompile Headers: Add REUSE_FROM signatureCristian Adam2019-09-171-3/+10
| | | | | | | Add the ability to share precompiled headers artifacts between targets. Fixes: #19659
* Merge topic 'clang-ipo-support'Brad King2019-09-031-2/+9
|\ | | | | | | | | | | | | | | | | | | dca9c33abc Tests: Remove old IPO test c856d4556b bindexplib: supporting llvm bitcode formats using llvm-nm 079b8e2916 Clang: prefer lld-link over link.exe 6e3655db2c Clang: add LTO support for GNU-command line clang on windows Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !3527
| * Clang: add LTO support for GNU-command line clang on windowsZsolt Parragi2019-08-271-2/+9
| |
* | Precompile headers: Add methods to generate PCH sourcesCristian Adam2019-08-283-0/+23
|/ | | | Co-Author: Daniel Pfeifer <daniel@pfeifer-mail.de>
* Merge topic 'solaris_clang'Brad King2019-08-192-0/+2
|\ | | | | | | | | | | | | 47937219ee Solaris: Add support for Clang compiler Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !3672
| * Solaris: Add support for Clang compilerLibor Bukata2019-08-092-0/+2
| | | | | | | | | | Inspired-by: Rainer Orth Fixes: #19456
* | Merge topic 'msvc-runtime-library-flang'Brad King2019-08-191-0/+5
|\ \ | | | | | | | | | | | | | | | | | | ea0294c281 Flang: Implement MSVC runtime library abstraction Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !3674
| * | Flang: Implement MSVC runtime library abstractionBrad King2019-08-091-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit fb3370b6a1 (MSVC: Add abstraction for runtime library selection, 2019-04-10, v3.15.0-rc1~229^2) we overlooked updating flags for Flang on Windows. Add them now and update the MSVCRuntimeLibrary Fortran test to work with Flang. Base the flags on those we already use for the GNU-like Clang targeting the MSVC ABI. Fixes: #19583
* | | Clang: Fall back to llvm-rc when rc is unavailableGregory Mitrano2019-08-141-0/+15
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change modifies how CMAKE_RC_COMPILER is configured to improve the out-of-box experience for developers using Clang on Windows. The previous behavior was to require the user to explicitly specify the resource compiler when CMake was called. The new behavior is to automatically attempt to locate the MSVC rc binary and use that if it's found. If rc is not available, CMake will now fall back to Clang's llvm-rc binary. With this change in place, trivial C/C++ programs can be generated with Ninja and Clang on Windows without running into errors about a missing resource compiler. Fixes: #19318
* | Make CMAKE_LINK_LIBRARY_FILE_FLAG work like CMAKE_LINK_LIBRARY_FLAGBrad King2019-08-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The `CMAKE_LINK_LIBRARY_FILE_FLAG` variable is meant for linkers that want library file paths to be preceded by a flag. This is used only for OpenWatcom to add the `library` argument before library file paths. Refactor the approach to treat `CMAKE_LINK_LIBRARY_FILE_FLAG` as a command-line string fragment to add just before the library file path. This has two advantages: * `CMAKE_LINK_LIBRARY_FILE_FLAG` now works like `CMAKE_LINK_LIBRARY_FLAG`. * `CMAKE_LINK_LIBRARY_FILE_FLAG` can now be an attached flag whose value is the library file path. Technically this is a change in behavior, but this setting was created for internal use and should be rarely used outside of CMake itself. Fixes: #19541
* | Android: Use unified toolchain in NDK r19+Brad King2019-07-266-3/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The NDK build system now uses only a single toolchain in <ndk>/toolchains/llvm/prebuilt/<host> 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
* | Android: Re-order system initialization to select sysroot lastBrad King2019-07-261-2/+2
| |
* | Android: Clarify name of internal variable for arch tripleBrad King2019-07-262-12/+12
| | | | | | | | The triple applies to more than just header locations.
* | Android: Select NDK host tag while determining systemBrad King2019-07-264-32/+32
| | | | | | | | | | The host tag is tied to the host platform and does not depend on any specific language or compiler.
* | AIX: Do not enable runtime linking by default anymoreBrad King2019-07-172-14/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 0f150b69d3 (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 9f5c2040bf (AIX: Explicitly compute executable exports for both XL and GNU, 2019-07-12) and commit 2fa920c0cd (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
* | AIX: Create import library for executables with exportsBrad King2019-07-164-5/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | AIX: Explicitly compute executable exports for both XL and GNUBrad King2019-07-152-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | AIX: Explicitly compute shared object exports for both XL and GNUBrad King2019-07-153-20/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On AIX, symbols in shared objects must be exported in order to be visible to dependents (similar to Windows). The AIX linker provides a `-bE:...` option to specify a file listing symbols to be exported. Compilers offer some features to help: * When the XL compiler is invoked with its `-qmkshrobj`/`-G` options for creating shared objects (without/with runtime linking), it recognizes when no explicit `-bE:...` linker option is specified and runs a `CreateExportList` tool provided with the compiler to compute one from the object files. Since commit d468a2c2cb (XL: Avoid copying archives into shared libraries that link them, 2011-04-07, v2.8.5~153^2) CMake runs `CreateExportList` explicitly to ensure it only looks at the object files and not any library files. * When the GNU compiler is invoked with its `-shared` option for creating shared objects, its internal `collect2` tool recognizes when no explicit `-bE:...` linker option is specified and computes one itself from the object files. However, it sometimes includes extra symbols such as `.__init_aix_libgcc_cxa_atexit`. Introduce our own internal `ExportImportList` script to compute symbol export lists from object files. Use a basic implementation for now: it can be extended as needed later. Update our shared library creation rules to run the script explicitly for both the XL and GNU compilers. Issue: #19163
* | AIX: Drop redundant -brtl flagsBrad King2019-07-152-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We removed `-brtl` in commit bce7a2a3a5 (AIX: Do not use -brtl to create shared libraries, 2013-03-11, v2.8.11~103^2~1) but it was added again by commit f254276fc1 (AIX,HP-UX: Fix RPATH handling when CMP0065 is set to NEW, 2015-12-11, v3.4.2~4^2). Since the latter commit we initialize the `CMAKE_{SHARED,MODULE}_LINKER_FLAGS` to use the `-brtl` linker flag. This is unnecessary because we already use the `-G` linker flag which implies `-brtl`. The latter commit also moved `-brtl` to `CMAKE_EXE_LINKER_FLAGS` from flags that were always included in executable link lines with CMP0065 OLD behavior and are not part of the change intended by CMP0065. Leave this for now as we've always enabled runtime linking for executables (and implicitly done so via -G for shared libraries and modules). Issue: #13997 Issue: #19163
* | XL: De-duplicate shared object creation flagsBrad King2019-07-155-5/+0
|/ | | | | | The XL `-qmkshrobj` flag creates shared objects on all platforms. Move the flag out of the per-platform modules into the per-compiler module for XL.
* CUDA: Implement MSVC runtime library abstractionBrad King2019-06-261-4/+19
| | | | | | | | | In commit fb3370b6a1 (MSVC: Add abstraction for runtime library selection, 2019-04-10, v3.15.0-rc1~229^2) we overlooked updating flags for CUDA on Windows, where nvcc uses MSVC as the host compiler. Add them now and update the MSVCRuntimeLibrary test to cover CUDA. Fixes: #19428
* Merge branch 'android-pie-cmp0083' into release-3.15Brad King2019-06-191-0/+20
|\ | | | | | | Merge-request: !3459
| * Android: ensure PIE behavior is consistent regardless CMP0083 policyMarc Chevrier2019-06-191-0/+20
| | | | | | | | | | | | | | | | | | In commit c4b4d8b3a6 (POSITION_INDEPENDENT_CODE: Manage link flags for executables, 2018-10-02, v3.14.0-rc1~395^2) we accidentally removed our Android-specific logic for PIE under the CMP0083 OLD behavior. Restore it and also implement Android-specific logic for CMP0083 NEW behavior. Fixes: #19393
* | Windows-MSVC.cmake: fix disabling of CMAKE_NINJA_CMCLDEPS_RCMarc-André Moreau2019-05-301-1/+3
| |
* | clang: setup correct configuration in gnu modeZsolt Parragi2019-05-231-5/+112
| |
* | Modules: Consistently use 2 space indentationKitware Robot2019-05-142-7/+7
| |
* | iOS: Only set the CMAKE_FIND_ROOT_PATH_MODE_* variables when not definedAlexandru Croitor2019-04-301-3/+9
| | | | | | | | This allows overriding them in a toolchain file.
* | iOS: Only look for packages in the provided CMAKE_FIND_ROOT_PATHsAlexandru Croitor2019-04-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Both CMAKE_FIND_ROOT_PATH_MODE_INCLUDE and CMAKE_FIND_ROOT_PATH_MODE_LIBRARY are set to "ONLY" when cross building to iOS, but appears that CMAKE_FIND_ROOT_PATH_MODE_PACKAGE was overlooked. This causes packages to be searched for in the host system as well, which is incorrect and can lead to linking issues. Set CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to "ONLY" as well. CMAKE_FIND_ROOT_PATH_MODE_PROGRAM is not touched, because a user might want to find programs / tools on the host system.
* | iOS: Allow setting multiple CMAKE_FIND_ROOT_PATH valuesAlexandru Croitor2019-04-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently the value is hardcoded to contain only the sysroot for the respective darwin platform. This means that it can not be changed in a custom toolchain file. Instead of overriding the value, simply append it. This is similar to how it is done in the Google provided Android toolchain file. The usecase is to allow specifying addiitonal roots to look for 3rd party packages which are definitely not present in the default sysroot.
* | iOS: Allow specifying CMAKE_MACOSX_BUNDLE in toolchain fileAlexandru Croitor2019-04-301-1/+3
| | | | | | | | | | | | | | | | | | | | Currently CMAKE_MACOSX_BUNDLE is always set to true when compiling for iOS. This poses a problem when using the source file variant of try_compile. Even if a custom value is passed via the CMAKE_FLAGS option, it would still be overridden by the Darwin.cmake file. Only set the value in case no other value was provided before.
* | MSVC: Do not add /W3 to CMAKE_<LANG>_FLAGS by defaultBrad King2019-04-193-4/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We do not add default warning flags on other compilers, and having a warning flag in the default flags makes it hard for projects to customize the warning level. They need to use string processing to remove `/W3` from `CMAKE_{C,CXX}_FLAGS`. Therefore we should drop it. However, projects may be using string processing to replace `/W3` with another flag, so we cannot simply drop it. Add a policy to drop it in a compatible way. Fixes: #18317
* | MSVC: Add abstraction for runtime library selectionBrad King2019-04-172-10/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace our hard-coded defaults for `/MD` and `/MDd` with a first-class abstraction to select the runtime library from an enumeration of logical names. We've long hesitated to do this because the idea of "runtime library selection" touches on related concepts on several platforms. Avoid that scope creep by simply defining an abstraction that applies only when targeting the MSVC ABI on Windows. Removing the old default flags requires a policy because existing projects may rely on string processing to edit them and choose a runtime library under the old behavior. Add policy CMP0091 to provide compatibility. Fixes: #19108
* | Merge topic 'ghs_os_dir'Brad King2019-04-081-11/+12
|\ \ | | | | | | | | | | | | | | | | | | | | | a1e6b414b9 GHS: Update GHS_BSP_NAME processing 266dadf868 GHS: Print status message regarding GHS_OS_DIR Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !3123
| * | GHS: Print status message regarding GHS_OS_DIRFred Baksik2019-03-291-11/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | -- Rename platform script so it runs before initial try_compile() in project() command. -- Fix incorrect variable name GHS_OS_DIR_OPTION -- Remove unnecessary ".*" from REGEX expression for GHS_CANDIDATE_OS_DIRS -- Forward GHS_OS_DIR_OPTION to try_compile() and preserve trailing whitespace of the variable.
* | | Merge topic 'vs2019-redist'Brad King2019-04-041-1/+4
|\ \ \ | |/ / |/| / | |/ | | | | | | | | 33ee779330 IRSL: Fix discovery of VS 2019 v142 toolset redistributables d8cf8380fb MSVC: Fix MSVC_TOOLSET_VERSION for VS 2019 v142 toolset Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !3186
| * MSVC: Fix MSVC_TOOLSET_VERSION for VS 2019 v142 toolsetBrad King2019-04-031-1/+4
| | | | | | | | | | | | | | | | This was forgotten in commit 626c51f47b (VS: Update for Visual Studio 2019 Preview 2, 2019-01-24, v3.14.0-rc1~74^2) when the toolset was first renumbered to `v142`. Issue: #19125
* | GHS: Add support for GHS Multi Generator in LinuxNaren Manimohan2019-03-211-1/+5
| |
generated by cgit v0.12 at 2024-12-26 19:47:15 (GMT)