2021-06-19 04:02:41 +08:00
|
|
|
// 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",
|
2021-07-27 00:24:18 +08:00
|
|
|
dependencies: ["NIOConcurrencyHelpers", "CNIOLinux"]),
|
2017-04-20 19:13:14 +08:00
|
|
|
.target(name: "NIO",
|
|
|
|
dependencies: ["CNIOLinux",
|
|
|
|
"CNIODarwin",
|
2020-09-22 01:03:41 +08:00
|
|
|
"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"]),
|
2021-03-31 19:52:04 +08:00
|
|
|
.target(name: "_NIOConcurrency",
|
|
|
|
dependencies: ["NIO"]),
|
2017-04-20 19:13:14 +08:00
|
|
|
.target(name: "NIOFoundationCompat", dependencies: ["NIO"]),
|
2018-03-14 00:24:54 +08:00
|
|
|
.target(name: "CNIOAtomics", dependencies: []),
|
|
|
|
.target(name: "CNIOSHA1", dependencies: []),
|
2017-04-20 19:13:14 +08:00
|
|
|
.target(name: "CNIOLinux", dependencies: []),
|
2021-07-08 18:04:53 +08:00
|
|
|
.target(name: "CNIODarwin", dependencies: [], cSettings: [.define("__APPLE_USE_RFC_3542")]),
|
2020-09-22 01:03:41 +08:00
|
|
|
.target(name: "CNIOWindows", dependencies: []),
|
2017-04-20 19:13:14 +08:00
|
|
|
.target(name: "NIOConcurrencyHelpers",
|
|
|
|
dependencies: ["CNIOAtomics"]),
|
|
|
|
.target(name: "NIOHTTP1",
|
2019-03-04 21:52:30 +08:00
|
|
|
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"]),
|
2019-04-06 00:38:34 +08:00
|
|
|
.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"]),
|
2018-03-14 00:24:54 +08:00
|
|
|
.target(name: "NIOWebSocket",
|
|
|
|
dependencies: ["NIO", "NIOHTTP1", "CNIOSHA1"]),
|
|
|
|
.target(name: "NIOWebSocketServer",
|
|
|
|
dependencies: ["NIO", "NIOHTTP1", "NIOWebSocket"]),
|
2019-07-26 22:42:05 +08:00
|
|
|
.target(name: "NIOWebSocketClient",
|
|
|
|
dependencies: ["NIO", "NIOHTTP1", "NIOWebSocket"]),
|
2018-05-11 13:22:24 +08:00
|
|
|
.target(name: "NIOPerformanceTester",
|
2019-10-11 23:04:08 +08:00
|
|
|
dependencies: ["NIO", "NIOHTTP1", "NIOFoundationCompat", "NIOWebSocket"]),
|
2018-09-24 17:24:09 +08:00
|
|
|
.target(name: "NIOMulticastChat",
|
|
|
|
dependencies: ["NIO"]),
|
2019-03-05 19:25:21 +08:00
|
|
|
.target(name: "NIOUDPEchoServer",
|
|
|
|
dependencies: ["NIO"]),
|
2019-03-31 23:18:11 +08:00
|
|
|
.target(name: "NIOUDPEchoClient",
|
|
|
|
dependencies: ["NIO"]),
|
2019-05-11 00:29:13 +08:00
|
|
|
.target(name: "NIOTestUtils",
|
2019-10-02 19:10:09 +08:00
|
|
|
dependencies: ["NIO", "NIOHTTP1"]),
|
2020-06-01 19:51:39 +08:00
|
|
|
.target(name: "NIOCrashTester",
|
|
|
|
dependencies: ["NIO", "NIOHTTP1", "NIOWebSocket", "NIOFoundationCompat"]),
|
2021-03-31 19:52:04 +08:00
|
|
|
.target(name: "NIOAsyncAwaitDemo",
|
|
|
|
dependencies: ["NIO", "NIOHTTP1", "_NIOConcurrency"]),
|
2017-04-20 19:13:14 +08:00
|
|
|
.testTarget(name: "NIOTests",
|
2019-05-25 01:00:17 +08:00
|
|
|
dependencies: ["NIO", "NIOFoundationCompat", "NIOTestUtils", "NIOConcurrencyHelpers"]),
|
2017-04-20 19:13:14 +08:00
|
|
|
.testTarget(name: "NIOConcurrencyHelpersTests",
|
2019-12-07 01:41:14 +08:00
|
|
|
dependencies: ["NIOConcurrencyHelpers", "NIO"]),
|
2017-04-20 19:13:14 +08:00
|
|
|
.testTarget(name: "NIOHTTP1Tests",
|
2019-05-11 00:29:13 +08:00
|
|
|
dependencies: ["NIOHTTP1", "NIOFoundationCompat", "NIOTestUtils"]),
|
2017-04-20 19:13:14 +08:00
|
|
|
.testTarget(name: "NIOTLSTests",
|
|
|
|
dependencies: ["NIO", "NIOTLS", "NIOFoundationCompat"]),
|
2018-03-14 00:24:54 +08:00
|
|
|
.testTarget(name: "NIOWebSocketTests",
|
|
|
|
dependencies: ["NIO", "NIOWebSocket"]),
|
2019-05-11 00:29:13 +08:00
|
|
|
.testTarget(name: "NIOTestUtilsTests",
|
|
|
|
dependencies: ["NIOTestUtils"]),
|
2019-10-18 07:03:44 +08:00
|
|
|
.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"]),
|
2021-03-31 19:52:04 +08:00
|
|
|
.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"]),
|
2018-03-02 09:52:07 +08:00
|
|
|
.library(name: "NIOFoundationCompat", targets: ["NIOFoundationCompat"]),
|
2018-03-14 00:24:54 +08:00
|
|
|
.library(name: "NIOWebSocket", targets: ["NIOWebSocket"]),
|
2019-05-11 00:29:13 +08:00
|
|
|
.library(name: "NIOTestUtils", targets: ["NIOTestUtils"]),
|
2017-04-20 19:13:14 +08:00
|
|
|
],
|
|
|
|
dependencies: [
|
|
|
|
],
|
|
|
|
targets: targets
|
|
|
|
)
|