summaryrefslogtreecommitdiffstats
path: root/Modules/CMakeSwiftInformation.cmake
Commit message (Collapse)AuthorAgeFilesLines
* Swift: repair RPATH handling for macOSSaleem Abdulrasool2020-03-111-4/+6
| | | | | | | | The configuration previously handled Linux properly but did not function on macOS as `ld64` does not support `:` delimited paths. Account for that by setting it to the empty string which will use multiple invocations of the `-Xlinker -rpath -Xlinker ...` pattern to compute the correct RPATH.
* Swift: support `-rpath` for executablesSaleem Abdulrasool2020-02-171-0/+5
| | | | This adjusts the flags to enable setting the RPATH for executables.
* Ninja: properly handle exports from Swift exesSaleem Abdulrasool2020-02-021-1/+3
| | | | | | This adds logic to properly handle Swift executables. Only executables marked as exporting symbols will now generate module interfaces for the executable.
* Swift: move windows handling into platform file (NFC)Saleem Abdulrasool2019-12-221-4/+0
| | | | | | | This moves the definition of the import library flags for Windows into a platform specific file (much like the Darwin `-sdk` flag). This is in preparation for re-use of the flag to make the flags handling for executables more precise.
* Merge topic 'swift-rpath-darwin'Brad King2019-11-181-1/+1
|\ | | | | | | | | | | | | ff6c336127 Swift: support `-rpath` on Darwin Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !4059
| * Swift: support `-rpath` on DarwinSaleem Abdulrasool2019-11-181-1/+1
| | | | | | | | | | | | | | | | | | Darwin also has the concept of RPATH. Additionally, the flag is identical to that on other Unixish platforms. Simply avoid the `-rpath` handling on Windows. This enables the use of `BUILD_WITH_INSTALL_RPATH` and `INSTALL_RPATH` with Swift targets on Darwin.
* | Merge topic 'swift-darwin-install-name'Brad King2019-11-181-1/+1
|\ \ | |/ |/| | | | | | | | | f935de6746 Swift: support `INSTALL_NAME_DIR` on Darwin Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !4060
| * Swift: support `INSTALL_NAME_DIR` on DarwinSaleem Abdulrasool2019-11-181-1/+1
| | | | | | | | | | | | | | Adjust the shared object rule to ensure that we honour the `INSTALL_NAME_DIR` property on Swift targets. This enables the use of `INSTALL_NAME_DIR` and `BUILD_WITH_INSTALL_NAME_DIR` on Darwin with Ninja.
* | Swift: Allow build and installed RPATHs to differSaleem Abdulrasool2019-11-121-0/+1
|/ | | | | | Define the RPATH separator to `:` so that CMake can reserve room to edit the ELF RPATH at install time. This enables the use of `BUILD_RPATH` and `INSTALL_RPATH` with differing values.
* Merge branch 'swift-rpath' into release-3.16Brad King2019-10-311-0/+4
|\ | | | | | | Merge-request: !3965
| * Swift: support `BUILD_RPATH` propertiesSaleem Abdulrasool2019-10-301-0/+4
| | | | | | | | | | Enable passing a RPATH to Swift shared libraries. This enables testing libraries before they have been installed.
* | Swift: correct flags for parallel jobsSaleem Abdulrasool2019-10-281-3/+3
|/ | | | | | | `-num-threads` is for the threading, not the job control. Use `-j` to launch the parallel jobs. This enables parallel builds for Swift again after driver updates preventing the parallelization through `-num-threads`.
* Merge topic 'swift-mode-flags'Brad King2019-08-191-0/+2
|\ | | | | | | | | | | | | | | 4d83e47c05 Swift: define `CMAKE_Swift_FLAGS` correctly Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: Ben Boeckel <ben.boeckel@kitware.com> Merge-request: !3684
| * Swift: define `CMAKE_Swift_FLAGS` correctlySaleem Abdulrasool2019-08-121-0/+2
| | | | | | | | | | Invoke `cmake_initialize_per_config_variable` to ensure that build type flags are properly initialised.
* | Merge topic 'swift-import-library-location'Kyle Edwards2019-08-191-2/+6
|\ \ | | | | | | | | | | | | | | | | | | | | | 5480f65ab1 Swift: honour `IMPLIB_LOCATION` property Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: Ben Boeckel <ben.boeckel@kitware.com> Merge-request: !3686
| * | Swift: honour `IMPLIB_LOCATION` propertySaleem Abdulrasool2019-08-121-2/+6
| |/ | | | | | | | | | | | | | | The rules did not account for the import library location (through `<TARGET_IMPLB>`) and instead would always write the import library to the default location (next to the shared library/executable). This prevented the use of `CMAKE_RUNTIME_OUTPUT_LOCATION` and `CMAKE_ARCHIVE_OUTPUT_LOCATION`.
* | Generator: support per-language link library flagSaleem Abdulrasool2019-08-091-0/+1
|/ | | | | | | | This enables the use of MSVC and Swift on Windows in a single project. MSVC uses no flag to indicate linked libraries while Swift uses `-l`. Add support for a language specific link library flag which takes precedence over the global `CMAKE_LINK_LIBRARY_FLAG` which preserves compatibility with earlier releases.
* Swift: correct SONAME flag for Darwin targetsSaleem Abdulrasool2019-08-061-1/+3
| | | | Adjust the build rules for Swift to fix the SONAME handling for Darwin.
* Swift: refactor rule construction to reduce duplicationSaleem Abdulrasool2019-07-171-16/+10
| | | | | | Use the placeholder expansion to avoid constructing the `-target` option by hand if specified. This reduces duplication and simplifies the rules.
* Swift: support SONAME on ELFish targetsSaleem Abdulrasool2019-07-111-2/+5
| | | | | | We should enable the soname to be setup for ELF shared libraries. Failure to do so generates binaries with incorrect names which prevents loading.
* Swift: support multithreaded compilationSaleem Abdulrasool2019-07-021-6/+10
| | | | | Query the number of logical CPUs available to enable parallel compilation for Swift.
* Swift: add rules for static linkingSaleem Abdulrasool2019-06-281-0/+6
| | | | | | The Swift driver recently learnt how to generate static libraries using the `-static` flag. This enables us to generate proper static libraries with dependency tracking with Swift as well.
* Support per-language library link flagsSaleem Abdulrasool2019-06-061-0/+2
| | | | | | | | | | This changes the behaviour of the generators to use a per-language library search path flag. This is needed for multi-language projects with different compilers (e.g. cl + gfortran). Since the adjusted variable has been part of the user settings, we control this based on a policy. Fixes: #19307
* Merge topic 'swift-wrapper'Brad King2019-05-291-1/+2
|\ | | | | | | | | | | | | 6baa80d1e3 Modules: correct linker wrapper flag for Swift Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !3390
| * Modules: correct linker wrapper flag for SwiftSaleem Abdulrasool2019-05-281-1/+2
| | | | | | | | | | This was sitting locally but was missed in previous commits. This enables the use of `LINKER:` when building Swift code bases.
* | Merge topic 'linker-preference'Brad King2019-05-291-0/+3
|\ \ | |/ |/| | | | | | | | | abea06efdf Modules: setup `CMAKE_Swift_LINKER_PREFERENCE` Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !3373
| * Modules: setup `CMAKE_Swift_LINKER_PREFERENCE`Saleem Abdulrasool2019-05-241-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | Swift's driver will invoke the C++ driver (`clang++`) to invoke the linker. Additionally, it will configure the command line to deal with the linkage runtime support object (`swiftrt.o` or `swiftrt.obj`) to be added at the right time (similar to C/C++). Since it indirects through `clang++` it will properly setup the linker invocation for C++ and C as well. This should permit the correct linker driver to be invoked in multi-language projects. Closes #19299
* | Ninja,Swift: correct response file handlingSaleem Abdulrasool2019-05-231-0/+2
|/ | | | | | | | The response file was being written but not used due to the wrong variable being configured for Swift. Swift does compile+link in a single phase and does not use the `<OBJECTS>` placeholder. Use the `<SWIFT_SOURCES>` placeholder instead for the response file substitution which serves the same purpose.
* Merge topic 'swift-flag-variables'Brad King2019-05-231-2/+10
|\ | | | | | | | | | | | | | | | | 24223ac84b Modules: add Swift MSVC_RUNTIME_LIBRARY flags 7e636fd8e0 Modules: add `CMAKE_Swift_FRAMEWORK_SEARCH_FLAG` 0fbf936b46 Modules: remove `CMAKE_INCLUDE_FLAG_SEP_Swift` Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !3353
| * Modules: add Swift MSVC_RUNTIME_LIBRARY flagsSaleem Abdulrasool2019-05-211-0/+8
| | | | | | | | | | | | This adds support for the newly minted `-libc` flag to the Swift driver invocation. These allow users to control the MSVC linkage properly on Windows targets.
| * Modules: add `CMAKE_Swift_FRAMEWORK_SEARCH_FLAG`Saleem Abdulrasool2019-05-211-0/+1
| | | | | | | | | | | | Swift supports frameworks and uses them across all OSes. They are added using the `-F` flag. There must be a space following the flag and before the parameter.
| * Modules: remove `CMAKE_INCLUDE_FLAG_SEP_Swift`Saleem Abdulrasool2019-05-211-2/+1
| | | | | | | | | | | | The include flag specifier should be specified multiply. The separator was being misused for adding a space after the `-I` flag. Correct this to get multiple include paths correct.
* | Ninja,Swift: pass along DEFINES/FLAGS/INCLUDESSaleem Abdulrasool2019-05-211-4/+4
|/ | | | | | | Since the Swift model does a single compile/link phase, we would not get the compile definitions, includes, and options past along to the build of the module. Compute these for the target when constructing the main command.
* Modules: add build rules for Swift Ninja supportSaleem Abdulrasool2019-05-161-14/+43
| | | | Add rules to support building Swift sources using Ninja.
* Modules: Introduce CMAKE_EFFECTIVE_SYSTEM_NAME to lookup compiler infoGregor Jasny2018-04-181-2/+2
| | | | | | | | | Create a `CMAKE_EFFECTIVE_SYSTEM_NAME` variable to use for looking up compiler information modules instead of using `CMAKE_SYSTEM_NAME` directly. This will allow multiple platforms to share the same set of compiler information modules without spelling out all of them. Issue: #17870
* Simplify CMake per-source license noticesBrad King2016-09-271-12/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Per-source copyright/license notice headers that spell out copyright holder names and years are hard to maintain and often out-of-date or plain wrong. Precise contributor information is already maintained automatically by the version control tool. Ultimately it is the receiver of a file who is responsible for determining its licensing status, and per-source notices are merely a convenience. Therefore it is simpler and more accurate for each source to have a generic notice of the license name and references to more detailed information on copyright holders and full license terms. Our `Copyright.txt` file now contains a list of Contributors whose names appeared source-level copyright notices. It also references version control history for more precise information. Therefore we no longer need to spell out the list of Contributors in each source file notice. Replace CMake per-source copyright/license notice headers with a short description of the license and links to `Copyright.txt` and online information available from "https://cmake.org/licensing". The online URL also handles cases of modules being copied out of our source into other projects, so we can drop our notices about replacing links with full license text. Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority of the replacements mechanically. Manually fix up shebang lines and trailing newlines in a few files. Manually update the notices in a few files that the script does not handle.
* Xcode: Obey SYSTEM keyword for includes (#15687)Gregor Jasny2016-08-091-0/+1
| | | | | | | | | | | | | CMake used to put all header search paths into HEADER_SEARCH_PATHS attribute. Unfortunately this attribute does not support to declare a search path as a system include. As a hack one could add a -isystem /path to the cflags but then include ordering is not deterministic. A better approach was chosen with this patch by not filling HEADER_SEARCH_PATHS at all and to populate the C, C++, and Fortran flags directly. The include paths used by Xcode should be now identical to the ones used by Unix Makefiles and Ninja generator.
* Add rudimentary support for the Apple Swift language with XcodeBrad King2015-07-061-0/+41
Allow the `Swift` language to be enabled with the Xcode generator for Xcode >= 6.1. Reject it on other generators and with older Xcode versions. Since Apple is the only vendor implementing the language right now, the compiler id can be just `Apple`.
generated by cgit v0.12 at 2024-12-28 23:03:17 (GMT)