The Swift Programming Language
Перейти к файлу
Michael Gottesman df71e6ab9d [cmake] Add support for exporting frameworks/libraries into cmake export files.
I think this was just an oversight. The new cmake 3.16 seems to choke if we do
not add SourceKit to the exports file since there are dependencies upon it in
other swift libraries.

(cherry picked from commit 8d712af965)
2020-07-27 10:34:37 +02:00
.github
apinotes [CMake] Stop compiling API notes files to a binary format (#19205) 2018-09-12 14:19:59 -07:00
benchmark Revert count(where:) 2019-02-05 10:59:15 -08:00
bindings/xml
cmake Always set the compatibility_version of linked dylibs on Darwin. 2019-02-22 14:56:18 -08:00
docs Set up testing with the standard libraries coming from the OS 2019-06-13 20:29:42 -04:00
include [index] Fix infinite loop while looking at superclasses 2019-03-29 16:58:35 -07:00
lib [5.1] Increase the stack size limit for running llvm codegen threads to 8MB 2019-04-03 18:55:17 -07:00
stdlib Fix off-by-one when initializing Data with discontiguous, underestimated sequences 2019-03-12 17:09:38 -07:00
test bump compiler version to 5.0.3 2019-08-27 16:28:56 +01:00
tools [cmake] Add support for exporting frameworks/libraries into cmake export files. 2020-07-27 10:34:37 +02:00
unittests Requestify the mangling-to-metadata APIs. 2019-02-05 23:18:24 -05:00
utils bump compiler version to 5.0.3 2019-08-27 16:28:56 +01:00
validation-test Disable following tests due to Swift in the OS changes: 2019-06-18 15:18:52 -07:00
.clang-format
.dir-locals.el .dir-locals.el: add flycheck setting for c++14 2018-01-12 16:24:24 -08:00
.flake8 Ignore flake8 warning W504 line break after binary operator. 2018-11-06 11:38:39 -08:00
.gitignore [benchmark] Adding tests for BenchmarkDriver 2018-08-17 00:32:04 +02:00
.mailmap Update mailmap 2018-05-24 09:34:48 -07:00
CHANGELOG.md Update CHANGELOG.md for recent changes, in particular source breaks 2018-12-17 16:31:43 -05:00
CMakeLists.txt bump compiler version to 5.0.3 2019-08-27 16:28:56 +01:00
CODEOWNERS Fix inverse order in CODEOWNERS file 2018-11-19 21:37:54 -08:00
CODE_OF_CONDUCT.md Created a clone of the code of conduct on Swift.org 2017-10-04 21:59:57 +08:00
CODE_OWNERS.TXT code owners: take ownership of the swift benchmark suite 2018-08-13 15:25:47 -07:00
CONTRIBUTING.md
LICENSE.txt
README.md Update the Swift 5.0 README to new jobs 2018-11-27 11:29:54 -08:00

README.md

Swift logo

Swift Programming Language

Architecture Swift 5.0 Package
macOS x86_64 Build Status Build Status
Ubuntu 14.04 x86_64 Build Status Build Status
Ubuntu 16.04 x86_64 Build Status Build Status
Ubuntu 18.04 x86_64 Build Status Build Status

Swift Community-Hosted CI Platforms

OS Architecture Build
Ubuntu 16.04 AArch64 Build Status

Welcome to Swift

Swift is a high-performance system programming language. It has a clean and modern syntax, offers seamless access to existing C and Objective-C code and frameworks, and is memory safe by default.

Although inspired by Objective-C and many other languages, Swift is not itself a C-derived language. As a complete and independent language, Swift packages core features like flow control, data structures, and functions, with high-level constructs like objects, protocols, closures, and generics. Swift embraces modules, eliminating the need for headers and the code duplication they entail.

To learn more about the programming language, visit swift.org.

Contributing to Swift

Contributions to Swift are welcomed and encouraged! Please see the Contributing to Swift guide.

To be a truly great community, Swift.org needs to welcome developers from all walks of life, with different backgrounds, and with a wide range of experience. A diverse and friendly community will have more great ideas, more unique perspectives, and produce more great code. We will work diligently to make the Swift community welcoming to everyone.

To give clarity of what is expected of our members, Swift has adopted the code of conduct defined by the Contributor Covenant. This document is used across many open source communities, and we think it articulates our values well. For more, see the Code of Conduct.

Getting Started

These instructions give the most direct path to a working Swift development environment. To build from source you will need about 2 GB of disk space for the source code and up to 70 GB of disk space for the build artifacts with full debugging. Depending on your machine, a clean build can take a few minutes to several hours. Naturally, incremental builds are much faster.

System Requirements

macOS, Ubuntu Linux LTS, and the latest Ubuntu Linux release are the current supported host development operating systems.

macOS

To build for macOS, you need Xcode 10.0. The required version of Xcode changes frequently, and is often a beta release. Check this document or the host information on https://ci.swift.org for the current required version.

You will also need CMake and Ninja, which can be installed via a package manager:

Homebrew

brew install cmake ninja

MacPorts

sudo port install cmake ninja

Instructions for installing CMake and Ninja directly can be found below.

Linux

For Ubuntu, you'll need the following development dependencies:

sudo apt-get install git cmake ninja-build clang python uuid-dev libicu-dev icu-devtools libbsd-dev libedit-dev libxml2-dev libsqlite3-dev swig libpython-dev libncurses5-dev pkg-config libblocksruntime-dev libcurl4-openssl-dev systemtap-sdt-dev tzdata rsync

Note: LLDB currently requires at least swig-1.3.40 but will successfully build with version 2 shipped with Ubuntu.

Build instructions for Ubuntu 14.04 LTS can be found here.

First create a directory for all of the Swift sources:

mkdir swift-source
cd swift-source

Note: This is important since update-checkout (see below) checks out repositories next to the Swift source directory. This means that if one clones Swift and has other unrelated repositories, update-checkout may not clone those repositories and will update them instead.

Via HTTPS For those checking out sources as read-only, HTTPS works best:

git clone https://github.com/apple/swift.git
./swift/utils/update-checkout --clone

Via SSH For those who plan on regularly making direct commits, cloning over SSH may provide a better experience (which requires uploading SSH keys to GitHub):

git clone git@github.com:apple/swift.git
./swift/utils/update-checkout --clone-with-ssh

Building Swift

The build-script is a high-level build automation script that supports basic options such as building a Swift-compatible LLDB, building the Swift Package Manager, building for various platforms, running tests after builds, and more.

There are two primary build systems to use: Xcode and Ninja. The Xcode build system allows you to work in Xcode, but Ninja is a bit faster and supports more environments.

To build using Ninja, run:

utils/build-script --release-debuginfo

When developing Swift, it helps to build what you're working on in a debug configuration while building the rest of the project with optimizations. Below are some examples of using debug variants:

utils/build-script --release-debuginfo --debug-swift # Swift frontend built in debug
utils/build-script --release-debuginfo --debug-swift-stdlib # Standard library built in debug
utils/build-script --release-debuginfo --debug-swift --force-optimized-typechecker # Swift frontend sans type checker built in debug

Limiting the amount of debug code in the compiler has a very large impact on Swift compile times, and in turn the test execution time. If you want to build the entire project in debug, you can run:

utils/build-script --debug

For documentation of all available arguments, as well as additional usage information, see the inline help:

utils/build-script -h

Xcode

To build using Xcode, specify the --xcode argument on any of the above commands. Xcode can be used to edit the Swift source code, but it is not currently fully supported as a build environment for SDKs other than macOS. The generated Xcode project does not integrate with the test runner, but the tests can be run with the 'check-swift' target.

Build Products

All of the build products are placed in swift-source/build/${TOOL}-${MODE}/${PRODUCT}-${PLATFORM}/. If macOS Swift with Ninja in DebugAssert mode was built, all of the products would be in swift-source/build/Ninja-DebugAssert/swift-macosx-x86_64/. It helps to save this directory as an environment variable for future use.

export SWIFT_BUILD_DIR="~/swift-source/build/Ninja-DebugAssert/swift-macosx-x86_64"

Ninja

Once the first build has completed, Ninja can perform fast incremental builds of various products. These incremental builds are a big timesaver when developing and debugging.

cd ${SWIFT_BUILD_DIR}
ninja swift

This will build the Swift compiler, but will not rebuild the standard library or any other target. Building the swift-stdlib target as an additional layer of testing from time to time is also a good idea. To build just the standard library, run:

ninja swift-stdlib

It is always a good idea to do a full build after using update-checkout.

Using Xcode

To open the Swift project in Xcode, open ${SWIFT_BUILD_DIR}/Swift.xcodeproj. It will auto-create a lot of schemes for all of the available targets. A common debug flow would involve:

  • Select the 'swift' scheme.
  • Pull up the scheme editor (⌘⇧<).
  • Select the 'Arguments' tab and click the '+'.
  • Add the command line options.
  • Close the scheme editor.
  • Build and run.

Another option is to change the scheme to "Wait for executable to be launched", then run the build product in Terminal.

Swift Toolchains

Building

Swift toolchains are created using the script build-toolchain. This script is used by swift.org's CI to produce snapshots and can allow for one to locally reproduce such builds for development or distribution purposes. E.x.:

  $ ./utils/build-toolchain $TOOLCHAIN_PREFIX

where $TOOLCHAIN_PREFIX is a string that will be prepended to the swift package name in the produced tar ball. For instance, if $TOOLCHAIN_PREFIX was macOS, the produced archive will have the name swift-macOS.tar.gz.

Beyond building the toolchain, build-toolchain also supports the following (non-exhaustive) set of useful options::

  • --dry-run: Perform a dry run build. This is off by default.
  • --test: Test the toolchain after it has been compiled. This is off by default.
  • --distcc: Use distcc to speed up the build by distributing the c++ part of the swift build. This is off by default.

More options may be added over time. Please pass --help to build-toolchain to see the full set of options.

Installing into Xcode

On macOS if one wants to install such a toolchain into Xcode:

  1. Untar and copy the toolchain to one of /Library/Developer/Toolchains/ or ~/Library/Developer/Toolchains/. E.x.:
  $ tar -xzf swift-macOS.tar.gz -C /
  $ tar -xzf swift-macOS.tar.gz -C ~/
  1. Specify the local toolchain for Xcode's use via Xcode->Toolchains.

Build Failures

Make sure you are using the correct release of Xcode.

If you have changed Xcode versions but still encounter errors that appear to be related to the Xcode version, try passing --clean to build-script.

When a new version of Xcode is released, you can update your build without recompiling the entire project by passing the --reconfigure option.

Make sure all repositories are up to date with the update-checkout command described above.

Testing Swift

See docs/Testing.md, in particular the section on lit.py.

Learning More

Be sure to look through the docs directory for more information about the compiler. In particular, the documents titled Debugging the Swift Compiler and Continuous Integration for Swift are very helpful to understand before submitting your first PR.

Building Documentation

To read the compiler documentation, start by installing the Sphinx documentation generator tool by running the command:

easy_install -U Sphinx

Once complete, you can build the Swift documentation by changing directory into docs and typing make. This compiles the .rst files in the docs directory into HTML in the docs/_build/html directory.

Many of the docs are out of date, but you can see some historical design documents in the docs directory.

Another source of documentation is the standard library itself, located in stdlib. Much of the language is actually implemented in the library (including Int), and the standard library gives some examples of what can be expressed today.

Build Dependencies

CMake

CMake is the core infrastructure used to configure builds of Swift and its companion projects; at least version 3.4.3 is required.

On macOS, you can download the CMake Binary Distribution, bundled as an application, copy it to /Applications, and add the embedded command line tools to your PATH:

export PATH=/Applications/CMake.app/Contents/bin:$PATH

On Linux, if you have not already installed Swift's development dependencies, you can download and install the CMake package separately using the following command:

sudo apt-get install cmake

Ninja

Ninja is the current recommended build system for building Swift and is the default configuration generated by CMake. Pre-built packages are available for macOS and Linux distributions. You can also clone Ninja next to the other projects and it will be bootstrapped automatically:

Via HTTPS

git clone https://github.com/ninja-build/ninja.git && cd ninja
git checkout release
cat README

Via SSH

git clone git@github.com:ninja-build/ninja.git && cd ninja
git checkout release
cat README