swift-nio/Package.swift

106 lines
4.6 KiB
Swift
Raw Normal View History

// swift-tools-version:5.2
2017-04-20 19:13:14 +08:00
//===----------------------------------------------------------------------===//
//
// This source file is part of the SwiftNIO open source project
//
// Copyright (c) 2017-2018 Apple Inc. and the SwiftNIO project authors
// Licensed under Apache License v2.0
//
// See LICENSE.txt for license information
// See CONTRIBUTORS.txt for the list of SwiftNIO project authors
//
// SPDX-License-Identifier: Apache-2.0
//
//===----------------------------------------------------------------------===//
import PackageDescription
var targets: [PackageDescription.Target] = [
Extract basic data structures to NIOCore. (#1895) Motivation: Currently the "core" NIO module (currently called NIO) contains two fairly distinct kinds of things. The first is the core abstractions and data structures: the things that all NIO programs must necessarily deal with. This includes our base abstraction protocols (e.g. `EventLoop`, `Channel`, and `ChannelHandler`), as well as our base data types (e.g. `ByteBuffer`, `SocketAddress`, `EventLoopFuture`). The second thing the core NIO module contains is the default POSIX sockets event-loop and channels. These are the mainline production loops for NIO programs, and are supported in the various BSD-like OSes to varying extents. These can be thought of as a baseline implementation of the core abstraction protocols that form the first part of NIO. These two fairly distinct use-cases have no particular reason to be glued together, and in fact in gluing them together we have done a bit of a disservice to our adopters. The biggest issue is that it has become impossible to write a NIO program or library that does not bring along the POSIX layer of NIO. This has made porting NIO to other platforms difficult (Windows has been painful, and Webassembly is coming down the road as well), and has also bloated the size of iOS/macOS applications that use NIO via NIOTransportServices, as all of these applications must bring along an event loop and several Channels they will not use. To that end, we plan to begin a scope of work to split the core NIO module in two. Specifically, we intend to extract the baseline protocols and data types into a new module, called `NIOCore`, which will be able to be the baseline NIO module. The end goal is that libraries that implement protocols on top of SwiftNIO should be able to depend solely on `NIOCore`, not `NIO`. This will allow NIO applications to bring along only the event loops they want or need, without needing to pay for the POSIX sockets implementation. This should also make porting easier, as there will be no pressure to bring the existing `NIO` module to new platforms if it does not fit well. Modifications: This is the first in a series of patches, which extracts some of the low-hanging fruit. In particular, it extracts: - `ByteBuffer` (and associated types) - `RecvByteBufferAllocator` - `CircularBuffer` This also adds in the backwards compatibility shim: the `NIO` package performs an exported import of `NIOCore`. This will allow this change to avoid breaking API. However, to make a clean break we intend not to release a new NIO minor version until we have completed our extraction. If we fail to do this it won't be the end of the world, we can release subsequent minor versions that continue to extract new types. However, as much as possible should go at once. This patch also duplicates a few methods and files. At the end of the patch series we need to reconcile this duplication. In many cases the duplication will no longer be necessary, but in some cases we may have necessary duplicates. Result: The first step along the road to better platform citizenship is taken.
2021-07-14 16:58:25 +08:00
.target(name: "NIOCore",
dependencies: ["NIOConcurrencyHelpers", "CNIOLinux"]),
2017-04-20 19:13:14 +08:00
.target(name: "NIO",
dependencies: ["CNIOLinux",
"CNIODarwin",
"CNIOWindows",
Extract basic data structures to NIOCore. (#1895) Motivation: Currently the "core" NIO module (currently called NIO) contains two fairly distinct kinds of things. The first is the core abstractions and data structures: the things that all NIO programs must necessarily deal with. This includes our base abstraction protocols (e.g. `EventLoop`, `Channel`, and `ChannelHandler`), as well as our base data types (e.g. `ByteBuffer`, `SocketAddress`, `EventLoopFuture`). The second thing the core NIO module contains is the default POSIX sockets event-loop and channels. These are the mainline production loops for NIO programs, and are supported in the various BSD-like OSes to varying extents. These can be thought of as a baseline implementation of the core abstraction protocols that form the first part of NIO. These two fairly distinct use-cases have no particular reason to be glued together, and in fact in gluing them together we have done a bit of a disservice to our adopters. The biggest issue is that it has become impossible to write a NIO program or library that does not bring along the POSIX layer of NIO. This has made porting NIO to other platforms difficult (Windows has been painful, and Webassembly is coming down the road as well), and has also bloated the size of iOS/macOS applications that use NIO via NIOTransportServices, as all of these applications must bring along an event loop and several Channels they will not use. To that end, we plan to begin a scope of work to split the core NIO module in two. Specifically, we intend to extract the baseline protocols and data types into a new module, called `NIOCore`, which will be able to be the baseline NIO module. The end goal is that libraries that implement protocols on top of SwiftNIO should be able to depend solely on `NIOCore`, not `NIO`. This will allow NIO applications to bring along only the event loops they want or need, without needing to pay for the POSIX sockets implementation. This should also make porting easier, as there will be no pressure to bring the existing `NIO` module to new platforms if it does not fit well. Modifications: This is the first in a series of patches, which extracts some of the low-hanging fruit. In particular, it extracts: - `ByteBuffer` (and associated types) - `RecvByteBufferAllocator` - `CircularBuffer` This also adds in the backwards compatibility shim: the `NIO` package performs an exported import of `NIOCore`. This will allow this change to avoid breaking API. However, to make a clean break we intend not to release a new NIO minor version until we have completed our extraction. If we fail to do this it won't be the end of the world, we can release subsequent minor versions that continue to extract new types. However, as much as possible should go at once. This patch also duplicates a few methods and files. At the end of the patch series we need to reconcile this duplication. In many cases the duplication will no longer be necessary, but in some cases we may have necessary duplicates. Result: The first step along the road to better platform citizenship is taken.
2021-07-14 16:58:25 +08:00
"NIOConcurrencyHelpers",
"NIOCore"]),
.target(name: "_NIOConcurrency",
dependencies: ["NIO"]),
2017-04-20 19:13:14 +08:00
.target(name: "NIOFoundationCompat", dependencies: ["NIO"]),
.target(name: "CNIOAtomics", dependencies: []),
.target(name: "CNIOSHA1", dependencies: []),
2017-04-20 19:13:14 +08:00
.target(name: "CNIOLinux", dependencies: []),
.target(name: "CNIODarwin", dependencies: [], cSettings: [.define("__APPLE_USE_RFC_3542")]),
.target(name: "CNIOWindows", dependencies: []),
2017-04-20 19:13:14 +08:00
.target(name: "NIOConcurrencyHelpers",
dependencies: ["CNIOAtomics"]),
.target(name: "NIOHTTP1",
dependencies: ["NIO", "NIOConcurrencyHelpers", "CNIOHTTPParser"]),
2017-04-20 19:13:14 +08:00
.target(name: "NIOEchoServer",
dependencies: ["NIO", "NIOConcurrencyHelpers"]),
.target(name: "NIOEchoClient",
dependencies: ["NIO", "NIOConcurrencyHelpers"]),
.target(name: "NIOHTTP1Server",
dependencies: ["NIO", "NIOHTTP1", "NIOConcurrencyHelpers"]),
.target(name: "NIOHTTP1Client",
dependencies: ["NIO", "NIOHTTP1", "NIOConcurrencyHelpers"]),
2017-04-20 19:13:14 +08:00
.target(name: "CNIOHTTPParser"),
.target(name: "NIOTLS", dependencies: ["NIO"]),
.target(name: "NIOChatServer",
dependencies: ["NIO", "NIOConcurrencyHelpers"]),
.target(name: "NIOChatClient",
dependencies: ["NIO", "NIOConcurrencyHelpers"]),
.target(name: "NIOWebSocket",
dependencies: ["NIO", "NIOHTTP1", "CNIOSHA1"]),
.target(name: "NIOWebSocketServer",
dependencies: ["NIO", "NIOHTTP1", "NIOWebSocket"]),
.target(name: "NIOWebSocketClient",
dependencies: ["NIO", "NIOHTTP1", "NIOWebSocket"]),
.target(name: "NIOPerformanceTester",
dependencies: ["NIO", "NIOHTTP1", "NIOFoundationCompat", "NIOWebSocket"]),
.target(name: "NIOMulticastChat",
dependencies: ["NIO"]),
.target(name: "NIOUDPEchoServer",
dependencies: ["NIO"]),
.target(name: "NIOUDPEchoClient",
dependencies: ["NIO"]),
.target(name: "NIOTestUtils",
dependencies: ["NIO", "NIOHTTP1"]),
.target(name: "NIOCrashTester",
dependencies: ["NIO", "NIOHTTP1", "NIOWebSocket", "NIOFoundationCompat"]),
.target(name: "NIOAsyncAwaitDemo",
dependencies: ["NIO", "NIOHTTP1", "_NIOConcurrency"]),
2017-04-20 19:13:14 +08:00
.testTarget(name: "NIOTests",
dependencies: ["NIO", "NIOFoundationCompat", "NIOTestUtils", "NIOConcurrencyHelpers"]),
2017-04-20 19:13:14 +08:00
.testTarget(name: "NIOConcurrencyHelpersTests",
dependencies: ["NIOConcurrencyHelpers", "NIO"]),
2017-04-20 19:13:14 +08:00
.testTarget(name: "NIOHTTP1Tests",
dependencies: ["NIOHTTP1", "NIOFoundationCompat", "NIOTestUtils"]),
2017-04-20 19:13:14 +08:00
.testTarget(name: "NIOTLSTests",
dependencies: ["NIO", "NIOTLS", "NIOFoundationCompat"]),
.testTarget(name: "NIOWebSocketTests",
dependencies: ["NIO", "NIOWebSocket"]),
.testTarget(name: "NIOTestUtilsTests",
dependencies: ["NIOTestUtils"]),
.testTarget(name: "NIOFoundationCompatTests",
dependencies: ["NIO", "NIOFoundationCompat"]),
2017-04-20 19:13:14 +08:00
]
let package = Package(
name: "swift-nio",
products: [
Extract basic data structures to NIOCore. (#1895) Motivation: Currently the "core" NIO module (currently called NIO) contains two fairly distinct kinds of things. The first is the core abstractions and data structures: the things that all NIO programs must necessarily deal with. This includes our base abstraction protocols (e.g. `EventLoop`, `Channel`, and `ChannelHandler`), as well as our base data types (e.g. `ByteBuffer`, `SocketAddress`, `EventLoopFuture`). The second thing the core NIO module contains is the default POSIX sockets event-loop and channels. These are the mainline production loops for NIO programs, and are supported in the various BSD-like OSes to varying extents. These can be thought of as a baseline implementation of the core abstraction protocols that form the first part of NIO. These two fairly distinct use-cases have no particular reason to be glued together, and in fact in gluing them together we have done a bit of a disservice to our adopters. The biggest issue is that it has become impossible to write a NIO program or library that does not bring along the POSIX layer of NIO. This has made porting NIO to other platforms difficult (Windows has been painful, and Webassembly is coming down the road as well), and has also bloated the size of iOS/macOS applications that use NIO via NIOTransportServices, as all of these applications must bring along an event loop and several Channels they will not use. To that end, we plan to begin a scope of work to split the core NIO module in two. Specifically, we intend to extract the baseline protocols and data types into a new module, called `NIOCore`, which will be able to be the baseline NIO module. The end goal is that libraries that implement protocols on top of SwiftNIO should be able to depend solely on `NIOCore`, not `NIO`. This will allow NIO applications to bring along only the event loops they want or need, without needing to pay for the POSIX sockets implementation. This should also make porting easier, as there will be no pressure to bring the existing `NIO` module to new platforms if it does not fit well. Modifications: This is the first in a series of patches, which extracts some of the low-hanging fruit. In particular, it extracts: - `ByteBuffer` (and associated types) - `RecvByteBufferAllocator` - `CircularBuffer` This also adds in the backwards compatibility shim: the `NIO` package performs an exported import of `NIOCore`. This will allow this change to avoid breaking API. However, to make a clean break we intend not to release a new NIO minor version until we have completed our extraction. If we fail to do this it won't be the end of the world, we can release subsequent minor versions that continue to extract new types. However, as much as possible should go at once. This patch also duplicates a few methods and files. At the end of the patch series we need to reconcile this duplication. In many cases the duplication will no longer be necessary, but in some cases we may have necessary duplicates. Result: The first step along the road to better platform citizenship is taken.
2021-07-14 16:58:25 +08:00
.library(name: "NIOCore", targets: ["NIOCore"]),
2017-04-20 19:13:14 +08:00
.library(name: "NIO", targets: ["NIO"]),
.library(name: "_NIOConcurrency", targets: ["_NIOConcurrency"]),
2017-04-20 19:13:14 +08:00
.library(name: "NIOTLS", targets: ["NIOTLS"]),
.library(name: "NIOHTTP1", targets: ["NIOHTTP1"]),
.library(name: "NIOConcurrencyHelpers", targets: ["NIOConcurrencyHelpers"]),
.library(name: "NIOFoundationCompat", targets: ["NIOFoundationCompat"]),
.library(name: "NIOWebSocket", targets: ["NIOWebSocket"]),
.library(name: "NIOTestUtils", targets: ["NIOTestUtils"]),
2017-04-20 19:13:14 +08:00
],
dependencies: [
],
targets: targets
)