Swiftpack.co - Swift Packages by Carthage

Swiftpack.co is a collection of thousands of indexed Swift packages. Search packages.

Packages published by Carthage

Carthage/Carthage 0.39.1
A simple, decentralized dependency manager for Cocoa
⭐️ 14,895
🕓 27 weeks ago
🔖 Release Notes

Releases

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days.
0.39.1
27 weeks ago
**Fixed** * Support visionOS by using -destination `xros`/`xrsimulator`. Make additive changes to `XCDBLD`’s `SDK`. (#3345). * Fix Makefile to only pass `-static-stdlib` when Xcodes are accommodated. (#3350). **Acknowledgments** Thanks to all contributors.
0.39.0
1 year ago
## Fixed - [In Xcode 14, Carthage does not create tvOS & watchOS builds when Bitcode is disabled · Issue #3292 · Carthage/Carthage](https://github.com/Carthage/Carthage/issues/3292) ## What's Changed * Add: --use-xcframeworks check by @ryu1sazae in https://github.com/Carthage/Carthage/pull/3204 * Fix typo in fileReadCorruptFile error description by @TTOzzi in https://github.com/Carthage/Carthage/pull/3231 * README.md: HTTP => HTTPS by @Schweinepriester in https://github.com/Carthage/Carthage/pull/3244 * Update Xcode12Workaround.md by @Huang-Libo in https://github.com/Carthage/Carthage/pull/3248 * Use modern Alamofire version in README by @jshier in https://github.com/Carthage/Carthage/pull/3200 * Fix issue where Carthage doesn’t build for watchOS or tvOS if bitcode is disabled in Xcode 14 by @daltonclaybrook in https://github.com/Carthage/Carthage/pull/3293 * Bump up version to 0.39.0 by @giginet in https://github.com/Carthage/Carthage/pull/3318 ## New Contributors * @ryu1sazae made their first contribution in https://github.com/Carthage/Carthage/pull/3204 * @TTOzzi made their first contribution in https://github.com/Carthage/Carthage/pull/3231 * @Schweinepriester made their first contribution in https://github.com/Carthage/Carthage/pull/3244 * @Huang-Libo made their first contribution in https://github.com/Carthage/Carthage/pull/3248 * @jshier made their first contribution in https://github.com/Carthage/Carthage/pull/3200 * @daltonclaybrook made their first contribution in https://github.com/Carthage/Carthage/pull/3293 **Full Changelog**: https://github.com/Carthage/Carthage/compare/0.38.0...0.39.0
0.38.0 — Prebuilt Parity
2 years ago
**Fixed** * Building XCFrameworks with nested dependencies no longer requires a platform-specific Build directory (i.e. `Carthage/Build/iOS`) to exist (#3135). **Added** * Prebuilt dependencies (for [binary only frameworks](https://github.com/Carthage/Carthage/blob/master/Documentation/Artifacts.md#binary-only-frameworks) and [GitHub release assets](https://github.com/Carthage/Carthage#archive-prebuilt-frameworks-into-one-zip-file)) may use XCFrameworks, which are checked for compatibility and extracted into the Build folder (#3123). See the section below on compatibility information for framework authors. Thanks @igstewart3! :tada: * Project lookup is faster for dependencies which contain multiple xcodeprojs (#3076). **Known issues** * `carthage archive` does not archive built XCFrameworks * Support for making an xcframework archive will be added in a future release. For now, manually create archives by building twice: once with the `--use-xcframeworks` option, and once without. Then, create a zip from the `Carthage/Build` folder. ## How to distribute XCFrameworks while retaining backwards compatibility Since Carthage lets users choose whether they want discrete frameworks or XCFrameworks, we recommend supporting both distribution formats in your binary assets. Replacing discrete frameworks with XCFrameworks in your assets is a **breaking change**, since it will require users to [reintegrate the framework with their project](https://github.com/Carthage/Carthage#migrating-a-project-from-framework-bundles-to-xcframeworks). ### Create separate `.framework.zip` and `.xcframework.zip` archives Starting in 0.38.0, Carthage follows a naming convention to distinguish between XCFrameworks and plain framework bundles: - A release asset with `.xcframework` in the name is considered to contain XCFrameworks - An asset with `.framework` in the name is considered to contain plain framework bundles - Carthage looks to narrow download candidates when comparable filenames are found → the comparison is ‘do the filenames match after removing one «.framework» or one «.xcframework» found string from the filename?'. This allows to Carthage to narrow down to one comparison-matched download, basing direction on whether `--use-xcframeworks` is flagged. Sets entirely 'not-matching-comparison' will see no removal of download candidates. #### GitHub release assets: Upload both archives to the release GitHub releases can have multiple files attached to them. Upload both zip files to your release following the above naming convention. See [the README](https://github.com/Carthage/Carthage#archive-prebuilt-frameworks-into-zip-files) for more information. #### Binary only frameworks: Specify both archives in the binary spec URL using an `alt=` parameter. [Binary project specifications](https://github.com/Carthage/Carthage/blob/master/Documentation/Artifacts.md#binary-project-specification) are JSON documents which map _one_ download URL to _one_ version. To provide multiple asset URLs, join the URLs with an `alt=` query parameter. For example: ```json { "1.2.3": "https://example.com/releases/MyFramework-v1.2.3.framework.zip?alt=https://example.com/releases/MyFramework-v1.2.3.xcframework.zip" } ``` Older versions of Carthage will request the whole URL and will receive the _first_ framework zip (since HTTP servers ignore unknown query parameters). Starting in 0.38.0, Carthage will parse out any `alt` URLs and request them as well, using the same naming convention we use for GitHub assets. For optimal backwards compatibility: - Create an upload a framework zip and an xcframework zip, and give them the same basename, i.e. `MyFramework-v1.2.3.framework.zip` and `MyFramework-v1.2.3.xcframework.zip`. - Publish the binary spec JSON with the framework zip's URL _first_, followed by an `alt=` parameter with the xcframework zip's URL. <details><summary><strong>Example workflow</strong></summary> Suppose we're releasing `v1.2.3` of a project called `MyFramework`: 1. Create an xcframeworks build using --use-xcframeworks: carthage build --use-xcframeworks --no-skip-current zip -r MyFramework-v1.2.3.xcframework.zip Carthage/Build 2. Create a plain frameworks build: carthage build --no-skip-current zip -r MyFramework-v1.2.3.framework.zip Carthage/Build 3. Upload both archives, `MyFramework-v1.2.3.xcframework.zip` and `MyFramework-v1.2.3.framework.zip`. 4. For projects on GitHub, [create a release](https://docs.github.com/en/github/administering-a-repository/managing-releases-in-a-repository#creating-a-release) and include both archives. For a binary-only framework, publish a new version to its spec JSON. Point to the xcframework archive using an `alt=` parameter: ```js { // ... "1.2.3": "https://example.com/releases/MyFramework-v1.2.3.framework.zip?alt=https://example.com/releases/MyFramework-v1.2.3.xcframework.zip" } ``` </details> ### Prefer building with module stability Carthage compares the Swift compiler version used to build an XCFramework [with the currently selected Swift version](https://github.com/Carthage/Carthage#swift-binary-framework-download-compatibility) — allowing the XCFramework to supercede a local-machine build if the downloaded XCFramework: * contains no bundles with «.swiftmodule»-suffixed files, or * any bundle with «.swiftmodule»-suffixed files contains Swift components built under [`BUILD_LIBRARIES_FOR_DISTRIBUTION`](https://swift.org/blog/library-evolution/) build setting and [the current Swift compiler version](https://github.com/Carthage/Carthage/pull/1303) is greater than 5.1, or * any bundle not passing the above was built with [the current compiler version](https://github.com/Carthage/Carthage/pull/1303). 〜 Carthage falls back to building a dependency from source if the prebuilt version is rejected. 〜 Note: [see particulars on Carthage’s determining factors for `BUILD_LIBRARIES_FOR_DISTRIBUTION`](https://github.com/Carthage/Carthage/releases/tag/0.35.0). ✨ This matches Carthage's existing behavior, but is notably different from Swift Package Manager’s behavior, which requires that _all_ XCFrameworks are built for distribution. When you're creating XCFrameworks for a GitHub release, be mindful of this, and consider setting `BUILD_LIBRARIES_FOR_DISTRIBUTION=YES` in your project. Future versions of Carthage's `archive` command may encourage this setting. If you choose to publish an XCFramework _without_ module stability (a.k.a. [`BUILD_LIBRARIES_FOR_DISTRIBUTION`](https://swift.org/blog/library-evolution/) build setting) enabled, consider a naming convention like `*-carthage-abi-unstable.xcframework` to indicate this to your users.
0.37.0 — Architectural Alchemy
3 years ago
**Fixed** * Building a framework using Xcode 12 fails with a build error from `xcrun lipo` (https://github.com/Carthage/Carthage/issues/3019). Fix by passing `--use-xcframeworks` and [re-integrating your dependencies as XCFrameworks](https://github.com/Carthage/Carthage#migrating-a-project-from-framework-bundles-to-xcframeworks), or by using a [workaround xcconfig on Intel-based Macs](https://github.com/Carthage/Carthage/blob/master/Documentation/Xcode12Workaround.md). **Added** * Carthage produces XCFrameworks instead of universal frameworks when `--use-xcframeworks` is passed. (https://github.com/Carthage/Carthage/pull/3071). Thanks @elliottwilliams! XCFrameworks contain multiple discrete framework bundles. Unlike universal frameworks (produced by `lipo`), an XCFramework can contain multiple versions of a framework which share the same processor architecture. Since Xcode 12 added Apple Silicon support to its simulator platforms, the device and simulator versions of a framework both build for `arm64`, hence requiring an XCFramework. To build XCFrameworks into your app, **run Carthage with `--use-xcframeworks` and drag the produced XCFrameworks into your Xcode target’s _Embedded binaries_ section**, _without_ using a `carthage copy-frameworks` script phase. ﹡See the README﹡ for [information on how to upgrade to XCFrameworks](https://github.com/Carthage/Carthage#migrating-a-project-from-framework-bundles-to-xcframeworks). XCFrameworks are the only supported way to build Carthage frameworks for Apple Silicon-based Macs. **Known issues** * `--use-xcframeworks` does not produce an XCFramework for `github` dependencies which download binaries. * Workaround: Pass `--no-use-binaries` to make Carthage rebuild the dependency from source, which will produce an XCFramework. * `carthage archive` does not archive built XCFrameworks, and `--use-xcframeworks` does not produce an xcframework for [`binary` dependencies](https://github.com/Carthage/Carthage/blob/0.36.1/Documentation/Artifacts.md#binary-only-frameworks). * Support for binary xcframeworks will be added in a future release. For now, continue integrating [`binary` dependencies](https://github.com/Carthage/Carthage/blob/0.36.1/Documentation/Artifacts.md#binary-only-frameworks) using the strategy of [platform-specific frameworks](https://github.com/Carthage/Carthage#if-youre-building-for-ios-tvos-or-watchos). **Notes** Under `--use-xcframeworks`, Carthage aims to accommodate something long relied upon: targets that 〈think about targets such as your dependencies ⋯ subdependencies ⋯ dependencies vended by others〉 …that link against «.framework»s in the directory of `Carthage/Build` ﹡as opposed to linking against «.framework»s in [Per-configuration Build Products Path (`CONFIGURATION_BUILD_DIR`)](https://gist.github.com/NSExceptional/2cd98300f7297b75d7b2d929effa2f15#per-configuration-build-products-path-configuration_build_dir).﹡ Such targets will see Carthage extract — for each platform the target builds for — such-platform’s «.framework» bundles from all XCFrameworks, copying them into a temporary directory, and then — via build setting injection into [`FRAMEWORK_SEARCH_PATHS`](https://gist.github.com/NSExceptional/2cd98300f7297b75d7b2d929effa2f15#framework-search-paths-framework_search_paths) — allowing the xcodebuild run an at-the-end-of-[`FRAMEWORK_SEARCH_PATHS`](https://gist.github.com/NSExceptional/2cd98300f7297b75d7b2d929effa2f15#framework-search-paths-framework_search_paths) opportunity to link those extracted-into-temporary-directory «.framework»s (and fulfill a successful compilation). <details> <summary><em>Well, to be more precise…</em></summary> 〜 Well, to be more precise, any scheme where the Carthage-focused target with build setting value for [`FRAMEWORK_SEARCH_PATHS`](https://gist.github.com/NSExceptional/2cd98300f7297b75d7b2d929effa2f15#framework-search-paths-framework_search_paths) specifically containing a subdirectory of `Carthage/Build` will have the at-the-end-of-[`FRAMEWORK_SEARCH_PATHS`](https://gist.github.com/NSExceptional/2cd98300f7297b75d7b2d929effa2f15#framework-search-paths-framework_search_paths) opportunity. </details> This behavior works for framework targets in most cases, since they link against but generally do not embed their framework dependencies, but requires changes if any part of a target’s build process requires the _exact path_ of the framework bundle. If you (_or developers consuming your framework_) encounter build errors when using `carthage build --use-xcframeworks`, you have a few options: - Update your project to link and embed XCFrameworks from `Carthage/Build`, then read the extracted framework from [`CONFIGURATION_BUILD_DIR`](https://gist.github.com/NSExceptional/2cd98300f7297b75d7b2d929effa2f15#per-configuration-build-products-path-configuration_build_dir). You won’t rely on the above ‘at-the-end-of-FRAMEWORK_SEARCH_PATHS opportunity’ behavior, but ﹡you will break compatibility with users who _aren’t_ using the `--use-xcframeworks` flag﹡, so consider other options, proceed with caution, and consider versioning this as a breaking change. - If Carthage fails while building a scheme that contains non-framework targets, break it up into multiple schemes, so that Carthage only builds the framework targets. - Modify your build phases to parse the [`FRAMEWORK_SEARCH_PATHS`](https://gist.github.com/NSExceptional/2cd98300f7297b75d7b2d929effa2f15#framework-search-paths-framework_search_paths) build setting and search each directory in order to find a Carthage framework, rather than hard-coding its path to a `Carthage/Build/<platform>` directory. <details> <summary><em>If you’re struggling to figure out how Carthage focuses on a target…</em></summary> 〜 If you’re struggling to figure out how Carthage focuses on a target within a Xcode project/workspace within a repo and subsequently widens out to choose a scheme based on that, head to https://github.com/Carthage/Carthage/issues/new and attach the label «focused-target» or just mention «focused-target» in the issue’s body text; please make the body text detailed, and priority will be given to issues regarding open source repositories. </details> **Acknowledgements** Thanks @olejnjak, @philipphofmann, and @daisuke-t-jp for their work on documenting the xcconfig workaround. More broadly, we appreciate the community of users who communicated about the problem, came up with a temporary workaround, and were patient while we architected a fix. Thanks @tmspzz, @gjeck, @nighthawk, @chrisballinger, @renep, and @elliottwilliams for their work reviewing pull requests.
0.36.1 — Workspace Well-Being
3 years ago
:information_source: This is a maintenance release to support integrating frameworks on Xcode 12.3 and above. :information_source: This release **does not** include forthcoming support for building XCFrameworks. Expect XCFrameworks in the next release, 0.37.0. **Fixed** * `carthage build` disables a validation added in Xcode 12.3 which prevents some Carthage-built frameworks from being embedded (https://github.com/Carthage/Carthage/pull/3095). * Xcode 12.3 warns when a target embeds framework with slices labeled for multiple platforms (even when the slices are all housed under different architectures); except, _some_ slight sets of platform pairs are permitted. Typically, Carthage's multi-arch frameworks are stripped at build time using `carthage copy-frameworks`, but they may be copied whole in [test targets](https://github.com/Carthage/Carthage#adding-frameworks-to-unit-tests-or-a-framework) and other rare circumstances. * When warnings-as-errors is enabled, this validation warning may fail the build. Carthage disables it internally by setting `VALIDATE_WORKSPACE=NO`. * If you see an error like `Building for iOS Simulator, but the linked and embedded framework 'REDACTED.framework' was built for iOS + iOS Simulator`, set VALIDATE_WORKSPACE=NO in your project's build settings. * Fixed [carthage creating too many tempoary directories during `copy-frameworks` phase](https://github.com/Carthage/Carthage/issues/3056) (Carthage/Carthage#3066). Thanks @tmspzz Thanks @olejnjak, @philipphofmann for improving the documentation since the last release. **Note** <details> <summary>Xcode (at the era of 12.3) does very little when Validate Workspace is enabled. If truly encompassing this facet is important to you…</summary> …try copying a Carthage Checkouts/Build directory to another location, editing Xcode projects to remove any targets that (aside from through `carthage copy-frameworks`) embed Carthage-built things, and copy the xcodebuild invocation from a run of `carthage … --verbose` and modify-it, removing VALIDATE_WORKSPACE=NO. </details>
0.36.0 - Portuguese Pastel
3 years ago
## ⚠️ This version doesn't fix the issue with Xcode 12. See https://github.com/Carthage/Carthage/issues/3019 ⚠️ **Fixed** * Prevent cross device issues in `copy-frameworks` (#3047). Thanks @rudedogdhc! Thank you to @nixnoughtnothing for improvements to the code base! Thank you to @tmspzz for reviewing pull requests!
0.35.1 - Continuous Commitment
3 years ago
## ⚠️ This version doesn't fix the issue with Xcode 12. See https://github.com/Carthage/Carthage/issues/3019 ⚠️ **Fixed** * Fixed copying files across different volumes (#3025). Thanks @rudedogdhc! **Added** * Sort frameworks so changes in .version files are easier to spot (#3015). Thanks @peteranny! * Support `NO_PROXY` or `no_proxy` environment variable (#2991). Thanks @okaverin! * Prevent re-downloading module stable binaries (#3040). Thanks @justAnotherDev! * Remove leftovers of failed archives unzips (#3035). Thanks @tattn! **Improved** * Spelling mistakes in README (#3021). Thanks @thomasaw! * Reflect carthage build requirements in README (#3045). Thanks @chrstphrchvz! * Installing carthage outside of protected folders no longer requires `sudo` (#3024). Thanks @cfelder! * Remove invalid archs by intersecting VALID_ARCHS and ARCHS (#2987). Thanks @jerbob92! Thank you to @jdhealy @tmspzz for reviewing pull requests!
0.35.0 - Carrageenan Cabaletta
3 years ago
Carthage now elides a [certain warning](https://github.com/Carthage/Carthage/blob/0.34.0/Source/CarthageKit/SwiftVersionError.swift#L25) about Swift compiler versions upon truths from three sources: - Swift compiler version (as queried by local machine’s `xcode-select` and possible `TOOLCHAINS` environment variable) being greater than 5.1 - that particular framework’s recorded Swift compiler being greater than 5.1 - that particular framework matching (somewhat) a [glob](https://en.wikipedia.org/wiki/Glob_(programming)#Syntax) (working from framework-bundle-root–level) of `Modules/*swiftmodule*/*.swiftinterface` - note: only one directory matching `Modules/*swiftmodule*/` will continue querying inside of it — with `FileManager.default.contentsOfDirectory` defining that - note: presence of particular architectures (armv7, i386, x86_64, etc.) are **not** taken into account **Note**: As `.swiftinterface` files emission [“currently [as of Swift 5.X] requires library evolution support”](https://swift.org/blog/library-evolution/index.html) — take warning of the Swift Compiler Team’s message that [“Library evolution trades off performance for flexibility”](https://swift.org/blog/library-evolution/index.html) and [comes with caveats](https://swift.org/blog/library-evolution/index.html#interaction-with--enable-testing). • :warning: Not every library vendor will desire to enable `BUILD_LIBRARY_FOR_DISTRIBUTION` in their project’s build settings, or even to field questions on bugs resulting from those adding that scope. _Be kind_ to library vendors that might weigh their potential maintenance/ongoing-qa-debugging work differently then your `BUILD_LIBRARY_FOR_DISTRIBUTION` desires. 〜 Thanks @DavidBrunow for this feature! **Dynamic Intelligent Platform Parsing** Previously, Carthage would propagate errors upon reading non-compiled-in values from `SUPPORTED_PLATFORMS` or `PLATFORM_NAME`. Carthage 0.35.0 [supports `SUPPORTED_PLATFORMS` or `PLATFORM_NAME` dynamically with intelligent parsing from `xcodebuild -showsdks -json`.](https://github.com/Carthage/Carthage/pull/3001) Carthage’s [`--platform` argument](https://github.com/Carthage/Carthage/commit/68d77602ac11e27f753450638527f6ea2a6bce85#diff-908d3140eab5f48b3e5f926de743ef52R232-R246) takes the same input of 2019-era SDKs — however, in alignment with the above: the default (a.k.a. “all”) parameter will allow dynamically-parsed SDKs to propagate. `carthage archive` [still uses the hardcoded four 2019-era SDKs](https://github.com/Carthage/Carthage/commit/68d77602ac11e27f753450638527f6ea2a6bce85#diff-db6bc809697a7fc656230029d748c3feR73-R76). The `carthage cleanup` command — existing on-master, but unshipped-in-tags — no longer makes sense (when set of SDKs are non-fixed across Xcode versions) and has been removed. Dynamic Platform Parsing can occur [from `xcodebuild -showsdks -json`](https://github.com/Carthage/Carthage/commit/68d77602ac11e27f753450638527f6ea2a6bce85#diff-bcd3b8bafc84006ccb8b16295b6707b0R139-R200) with fallbacks to [`BuildSetting` extraction from a Xcode-bundled `xcodeproj`](https://github.com/Carthage/Carthage/commit/68d77602ac11e27f753450638527f6ea2a6bce85#diff-2c8b811867554fe0cd24adead2bd16daR326-R368), and beyond that [falling back to hardcoded 2019-era values](https://github.com/Carthage/Carthage/commit/68d77602ac11e27f753450638527f6ea2a6bce85#diff-2c8b811867554fe0cd24adead2bd16daR380). ⤵️ **Note**: _the dynamic parsing **will** omit SDKs — such as DriverKit — where JSON-derived `canonicalName` and `platform` do not share a common prefix · DriverKit has an ouptut `canonicalName` similar to «driverkit.macosx19.0»._ **Other Breaking Changes** - [Track static frameworks in `.version` files](https://github.com/Carthage/Carthage/pull/2900). Thanks @elliottwilliams! - Old carthage versions will still behave erroneous — but not propagate errors — after parsing sets of newer `.version` files output for Swift static frameworks. - To guarantee output of newer `.version` files for affected Swift static frameworks, change Swift versions and rerun Carthage with the `--cache-builds` flag (even temporarily), or delete `.framework` bundles for affected Swift static ones and rerun Carthage with the `--cache-builds` flag. - [For GitHub Release assets, expand permitted MIME types to include `application/x-zip-compressed`](https://github.com/Carthage/Carthage/pull/2877). Thanks @MatkovIvan! - [Reject invalid](https://github.com/Carthage/Carthage/pull/2765) [binary archives containing the same framework multiple times](https://github.com/Carthage/Carthage/pull/2791). Thanks @tmspzz! - [For binary-spec-ed dependencies and GitHub Release downloads, copy dSYMs if any architecture matches current binary — also affects CarthageKit consumers](https://github.com/Carthage/Carthage/pull/2776). Thanks @hlineholm! - [Conflict less in concurrent strip-framework–dedicated Carthage process invocations via different underlying copying](https://github.com/Carthage/Carthage/pull/2796) — [rather than overwrite straight from process, now temp directory usage prevents conflicts on certain same-file/same-path writes](https://github.com/Carthage/Carthage/pull/2809). Thanks @kalkwarf! - [Fallback to dSYM version parsing for more cases before invalidating cached builds](https://github.com/Carthage/Carthage/pull/2865). Thanks @kmcbride! - [Add `--use-netrc` flag](https://github.com/Carthage/Carthage/pull/2774) under which [basic `~/.netrc` files](https://github.com/Carthage/Carthage/blob/f94766acc9bee35e295eea03c282472c49f49800/Tests/CarthageKitTests/NetrcSpec.swift) facilitate [`binary`-specified framework download](https://github.com/Carthage/Carthage/blob/f656edfe35651b54eec50d814e79d079f8eea7c4/Documentation/Artifacts.md#binary-only-frameworks) authentication. Thanks @mollyIV! **Stability** - [Fix various cases of «Segmentation Fault 11»](https://github.com/Carthage/Carthage/pull/2908). Thanks @taisukeh! - [Extend error messages when reading certain binaries](https://github.com/Carthage/Carthage/pull/2917). Thanks @hlineholm! **Security Enhancing Breaking Change** - [Prevent directory traversal through additional sanitization of `git`-specified repository URL components — specifically nul characters (`\u{0000}`) and periods (`\u{0023}`)](https://github.com/Carthage/Carthage/search?q=%22prevent+directory+traversal%22&type=Commits). Thanks @manicmaniac! - Replacement strings include repeated «Full Width Full Stops» (`\u{FF0E}`) and replacement `␀` (`\u{2400}`). - URL components not starting with periods (`\u{0023}`) _will not_ see inserted «Full Width Full Stops» (`\u{FF0E}`). **Breaking — For Apps Importing Carthage Kit and XCDBLD** <details><summary>For Apps Importing Carthage Kit and XCDBLD</summary></br> - Removed: `XCDBLD.Platform` — replaced (not one-for-one) by `struct SDK` with new method `SDK.platformSimulatorlessFromHeuristic`. - Removed: `XCDBLD`’s enum-based `SDK` — replaced by `struct SDK`. - Removed: `XCDBLD.SDK.platform` and `XCDBLD.SDK.allSDKs`. - Changed: Hashing and equality for `XCDBLD.SDK` is case-insensitive. - Canonical casing for SDK names available through `SDK.knownIn2019YearSDKs` and `SDK.setFromJSONShowSDKs`. - Changed: Various type signature changes [removing `XCDBLD.Platform` and incorporating `XCDBLD.SDK`](https://github.com/Carthage/Carthage/commit/68d77602ac11e27f753450638527f6ea2a6bce85). - Removed: `SDK.from(string:)` — replaced by `SDK.init(name:simulatorHeuristic)`. - Passing an empty string as `simulatorHeuristic` is usually the foremost codepath. - SDK.init(rawValue:) is **not intended** for wide spread use · as it’s limited to only 2019-era hardcoded SDKs. - Removed: `BuildSettings.buildSDKs: SignalProducer<SDK, CarthageError>` — replaced with `BuildSettings.buildSDKRawNames: Set<String>`. - Made Public: Various [`VersionFile`-related API](https://github.com/Carthage/Carthage/pull/2931). Thanks @acecilia! </summary></details> **Thanks to all Contributors** Thank you to @CosynPa, @sidepelican, @chuganzy, @sstadelman (#2781), @giginet (#2761), @ikesyo (#2886, #2785, #2784), @DavidBrunow (#2966, #2967), @mvalentiner, @gubikmic, @sticksen, @nteissler, @ismetanin, @brandonlee503, @yhkaplan, and @tmspzz for improvements to the codebase, tests, and documentation.
0.34.0 - Barometric Ballasting
4 years ago
**⚠️ Carthage source only builds on Xcode 10.0+, thus requiring [macOS High Sierra 10.13.6](https://support.apple.com/en-us/HT208864). ⚠️** Additional workarounds to enable Xcode 11.0, 11.1, and 11.2 betas have been added; see below. **Fixed** * ASCII alphabet for Semantic Version [pre-release](https://semver.org/#spec-item-9) and [build metadata](https://semver.org/#spec-item-10) components [now includes uppercase and lowercase W](https://github.com/Carthage/Carthage/pull/2806/files#diff-aa0796654f69d3d5ad0a58b156377953R37), fixing an omission and completing the alphabet (#2805 #2806). Thanks @drakerr! * Workaround Swift 5.1 compiler crash bug to allow the compilation of Carthage itself on Xcode 11, Xcode 11.1, and Xcode 11.2 betas (#2859). Thanks @michaelmcguire! **Breaking — For Apps Importing Carthage Kit** <details><summary>Removed — as a library dependency — <code>SwiftPM</code> and <code>llbuild</code> and reinstated <code>struct CarthageKit.SemanticVersion</code>.</summary> </br>A [bug in the-tool-SwiftPM's package resolution](https://github.com/apple/swift-package-manager/pull/2197) resulted in disregard for the (crucial) ‘resolved file’ when resolving branch-based dependencies. Which would put us in the position of needing any commit of `apple/swift-package-manager` that didn’t specify its dependency on `apple/swift-llbuild` in the branch-based style. Also criteria for the above, working Swift 4.2.X manifests and compilation _and_ working Swift 5.X manifests and compilation. No such commit of `apple/swift-package-manager` could be found. In addition, some confusion [around `llbuild`'s `sqlite3`](https://github.com/apple/swift-llbuild/commit/f1c9ad9a253cdf1aa89a7f5c99c30b4513b06ddb#diff-37ca2dd15ca0f6b1b49e78db084ef5b9L5-L10) linkage made criteria even more confusing. - Some initializers and methods on `struct Carthage.SemanticVersion` have differences from the previous incarnation found in v0.33.0. - Reinstate `struct CarthageKit.SemanticVersion` in all callsites in codebase and tests, removing `SPMUtility.Version`. - No longer necessary to `import struct Foundation.URL` with the removed import of SPMUtility. - Makefile removes complications which previously supported `llbuild`'s `sqlite3` linkage. - Working Swift 4.2.X compilation is [necessary to support building](https://github.com/Homebrew/brew/blob/7dd0466/Library/Homebrew/os/mac/xcode.rb#L18) for [macOS High Sierra](https://en.wikipedia.org/wiki/MacOS_High_Sierra) on Homebrew bottling infrastructure. </details> **Important** Future updates will address Catalyst and building of XCFrameworks. Thank you for your patience. Thank you to @jdhealy, @sstadelman, @tmspzz, @giginet, @olejnjak, and @ikesyo for improvements to the codebase and the infrastructure. Thank you to @mdiep, @tmspzz, @giginet, and @ikesyo for reviewing pull requests!
0.33.0 - Astrometric Associations
4 years ago
**⚠️ Carthage source only builds on Xcode 10.0+, thus requiring [macOS High Sierra](https://en.wikipedia.org/wiki/MacOS_High_Sierra). ⚠️** In particular, `carthage` compiles under Swift 4.2 and 5.0 with Xcode 10.1 and 10.2. **Fixed** * In cases where `device` and `simulator` destined builds are merged into a single bundle, also merge `-Swift.h` header files from each with [active inclusion of target conditionals](https://github.com/Carthage/Carthage/pull/2748/files#diff-f66644e8cfbcad3c3826395a690ddfbcR367) (#2723, #2748). Thanks @DavidBrunow, @VictorNouvellet, and @buranmert! * [Currently limited](https://github.com/Carthage/Carthage/blob/87e2198/Source/CarthageKit/FrameworkExtensions.swift#L300) to a single pair of `-Swift.h`-suffixed files. Should be sufficient for the vast majority of frameworks. * Under `--cache-builds` mode — * Support headerless Swift-containing frameworks via dSYM parsing (#2622). Thanks @blender! * When run with `--no-skip-current`, produce `.version` files for those additional frameworks (#2636). Thanks @blender! * In support of community tooling, embed partial toolchain information (often `swiftlang` and `clang` versions) in `.version` files for Swift-containing frameworks. Expect these `.version` files to contain different output between Carthage v0.33.0 and previous Carthage versions (#2585, #2707). Thanks @giginet and @kenji21! **Notable** * For file system objects at some level of `Carthage/Checkouts/DependencyX`, delete with `FileManager.removeItem(at:)` if using `--use-submodules` and something exists there that’s not a directory housing a `.git` subdirectory. This matches Carthage’s existing deletion behavior of checkouts without `--use-submodules`. Use caution. (#2654). * In Cartfiles, specifications with `github` at the beginning of the line now error when followed by non-http-or-https-schemed URLs (often `ssh://` or `git://` schemed). We long-standing queried these with web requests, so now errors output earlier in the process with more helpful messaging (#2379). Thanks @ikesyo! * Static frameworks under `--cache-builds` mode highly likely to proceed errantly cache-valid ≈ late caught bug — * Will be correctly cache-invalid upon a version-specification change (including changing the specified SHA); also, upon a toolchain change for a Swift-containing static framework (including after a different `xcode-select`). * The first run of a never-modified-by-Carthage-v0.33.0 `.version` file for a Swift-containing static framework under Carthage v0.33.0 will also cache-invalidate it. * `carthage build <framework>` without `--cache-builds` will always attempt rebuilding it and it's dependencies. <details> <summary><strong>Note for Apps Importing CarthageKit.framework</strong></summary> * Carthage (the CLI executable) is now built exclusively with [SwiftPM](https://github.com/apple/swift-package-manager/). In effect, the Cartfile supporting `CarthageKit.framework` has been removed. Consuming CarthageKit is now [done through SwiftPM](https://swift.org/getting-started/#using-the-package-manager) and CarthageKit is now a static library. </details> **On environment variable [`GIT_SSH_COMMAND`](https://git-scm.com/docs/git#Documentation/git.txt-codeGITSSHCOMMANDcode)** * An SSH prompt (invisble to a `carthage` user) could stop progression when encountering a host not yet public-key-fingerprint verified by the user. Carthage now outputs proper messaging at that point, at the expense of [`GIT_SSH_COMMAND`](https://git-scm.com/docs/git#Documentation/git.txt-codeGITSSHCOMMANDcode) no longer being honored (#2734). Thanks @jlawton! **Improved** * Report read errors from files pointed to by `SCRIPT_INPUT_FILE_LIST_` variables (#2668). Thanks @ferranpujolcamins! * More efficient, less errant querying of git’s representation of file system objects via `ls-tree` (#2617). Thanks @CosynPa! * More efficient `git submodule sync` over multiple dependencies (#2643). Thanks @mdiep! Thank you to @FranklinYu, @DivineDominion, @musbaalbaki, and @salbertson for improvements to the documentation. Thank you to @mxcl, @giginet, @olejnjak, and @ikesyo for improvements to the codebase and the infrastructure. Thank you to @blender, @mdiep, @giginet, @DavidBrunow, @VictorNouvellet, and @ikesyo for reviewing pull requests!
Carthage/Commandant 0.18.0
Type-safe command line argument handling
⭐️ 422
🕓 3 years ago
🔖 Release Notes

Releases

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days.
0.18.0
3 years ago
_This release drops support for Swift 5.0-5.1. Only Swift 5.2+ is now supported._ - ✨ Support for Apple Silicon (arm64) Macs (#158). Thanks, @chris-araman!
0.17.0
4 years ago
_This release drops support for Swift 4.2. Only Swift 5 is now supported._ - Remove Result dependency (#146, #151). Thanks @daltonclaybrook & @giginet! Thank you @mdiep & @giginet for reviewing pull requests!
0.16.0
4 years ago
_This release drops support for Swift 4.0/4.1 (#142) and is likely the last release to support Swift 4.2._ ## Added - Allow setting the help command's description (#136). Thanks @Pyroh! - Support Swift 4.2 (#137). Thanks @ikesyo! - Support Swift 5.0 (#142). Thanks @norio-nomura! Thank you to @mdiep, @ikesyo, @blender and @norio-nomura for reviewing pull requests!
0.15.0
5 years ago
_This release drops support for Swift 3.x (#135)._ ## Added - Add CocoaPods support (#132, #134). Thanks @phatblat! ## Changed - Update Result to 4.0 (#130). Thanks @ikesyo! Thank you to @mdiep, @ikesyo, @NachoSoto and @blender for reviewing pull requests!
0.14.0
5 years ago
## Added - Add `Argument.usageParameter` to improve help messages (#129) Thanks @benasher44! ## Fixed - Improve Xcode 9.3 and Swift 4.1 support (#123, #125, #126, #127) Thanks @ikesyo! Thank you to @mdiep and @blender for reviewing pull requests!
0.13.0
6 years ago
## Added - Return self from `register(_:)` for method chaining (#111) Thanks @ikesyo! - Support strict argument values (#117) Thanks @nekrich! ## Removed - Removed deprecated APIs (#106) Thanks @ikesyo! ## Fixed - Use default command if options are present (#101) Thanks @xinsight! - Improve support for Xcode 8.3 and later & Swift 3.1 and later (#103, #109, #112, #113, #115) Thanks @ikesyo & @iosdevzone! - Fix scrambled commands (#118) Thanks @ikesyo! Thank you to @mdiep for reviewing pull requests!
0.12.0
7 years ago
## Added - Support for arguments array in `Option` (#86) Thanks @Antondomashnev! ## Fixed - Swift 3.1 compatibility, especially on Linux (#97, #99) Thanks @ikesyo! - Fix switch keys being ignored when a `Switch` contains a flag (#95, #96) Thanks @natanrolnik! Thank you to @mdiep for reviewing pull requests!
0.11.3
7 years ago
## Fixed - [CI] Fix Travis deploy (#81). Thanks @jpsim! - [SwiftPM] Remove test dependencies from `Package.swift` on Linux (#83). Thanks @ikesyo! - [SwiftPM] Loosen `Result` version constraint (#84). Thanks @ikesyo! Thank you to @mdiep for reviewing pull requests!
0.11.2
7 years ago
- Add missing `@available`s to enums to help consumers upgrade to new Swift 3 APIs. - Fix build issue on Linux using SPM. Thanks @ikesyo, @NachoSoto, @norio-nomura and @mdiep for making this release possible 🎉.
0.11.1
7 years ago
_This release drops support for Swift 2.2 and 2.3._ ## Fixed - Semantic Versioning (and Swift Package Manager) compatibility (#75, 4e056dd). Thank you to @mitsuse for filing the issue!

Swiftpack is being maintained by Petr Pavlik | @ptrpavlik | @swiftpackco | API | Analytics