swift-developers-japan
main / swiftpm
2
1
https://github.com/apple/swift-package-manager/blob/swift-4.0-branch/Documentation/PackageDescriptionV4.md 1
1
…と打ってたら、みんなそれっぽいですね( ´･‿･｀)
isDevelopment が取れたコミットは swift-4.0-branch にもないので、忘れ去られているだけなのかと。
1carthage update 相当のことをするにはどうすればいいんだと思って↓見たらまだ pinning とか書いてあってがっかりしてたけど普通に swift package update でできた。 https://github.com/apple/swift-package-manager/blob/master/Documentation/Usage.md 
1
-Xswiftc -static-stdlibを使ってビルドしたバイナリになりそうです。 https://github.com/realm/SwiftLint/pull/1951 https://github.com/jpsim/SourceKitten/pull/443
swift package update するか、もしくは Package.resolved を削除および swift package reset してから swift build すると再現します。 A = swtws, B = TweetupKit, C = OAuthSwift です。 https://github.com/swift-tweets/swtws
swift build では -fmodule が有効化するのに swift package generate-xcodeproj の xcode では Build Settings > Enable Modules = NO になっているために モジュール対応モードでコンパイルされないため、 そのモジュール自身が @import を使っているとコンパイルできない というトラブルを踏んでるんですが、何か知見のある人いますか？ 該当のリポジトリで立ってるissueでは手動設定が言及されているけど https://github.com/stephencelis/SQLite.swift/issues/691#issuecomment-339612232 
Package.swiftとは別のSwiftWorkspace.jsonを導入しようというモノらしい。 https://forums.swift.org/t/package-manager-workspace/10667
-l{モジュール名}
$ swift build Compile Swift Module 'MyPMLib' (1 sources) Linking ./.build/x86_64-apple-macosx10.10/debug/libMyPMLib.dylib $ swift -I .build/debug/ -L .build/debug/ -lMyPMLib Welcome to Apple Swift version 4.1 (swiftlang-902.0.48 clang-902.0.39.1). Type :help for assistance. 1> import MyPMLib 2> hello() Hello? 3> 
1
swift package generate-xcodeprojがC言語系のターゲットを生成する際module.modulemapにフルパスでヘッダが記載されるため生成されたXcodeプロジェクトがポータブルにならない、を改善するパッチがマージされました。 https://github.com/apple/swift-package-manager/pull/1602
Yamsでやってるので。 https://github.com/jpsim/Yams
Stencilには含まれていないのがネックかな。 https://github.com/ishkawa/DIKit/blob/master/Package.swift
swift-DEVELOPMENT-SNAPSHOT-2018-07-11-aでPackageDescription API v3が削除されたため、いくつかのパッケージがビルド出来なくなった… https://github.com/apple/swift-package-manager/commit/d9ae3a84d4860cd601ff2f336859a46f11cccc0c
swift test 2>&1 | xcprettyとすればxcpretty使えるらしい。 https://forums.swift.org/t/swift-test-output-format/14702/13
1 
@testable有効にしてテストするのはありかも。Xcodeでのテストで同じようなことはしています https://github.com/ReactiveCocoa/ReactiveSwift/blob/2463d83d0c896ac046c2b85377e583b72373b831/script/build#L35
@testable import するテストはファイルを分けて、ファイル全体を #if DEBUG で囲う方向でやってみます。 (-D DEBUG が渡っていることは確認しました) 1 SWIFT_DETERMINISTIC_HASHING=1
2xcodeprojからDIKit.framework以外の要素を手動で削除してしまえば良いのかも。 1Set 使っていてこの PackageGraph から諸々生成しているので、ランダムシードの影響受けるのは必至なのですが、手元で試した限り env SWIFT_DETERMINISTIC_HASHING=1 swift package generate-xcodeproj でも阻止できないので、やっかいですね。 2
1 - there is no good way to control the ordering of the `Products` group in the main group; it needs to be added last in order to appear after the other references 1Package.swift のロード（実行）のコマンドは https://github.com/apple/swift-package-manager/blob/106115d356f750223dbd4419c3f39f8fc2da66f7/Sources/PackageLoading/ManifestLoader.swift#L310-L329 この辺だと思っていて、そこでconfigurationを渡していないようなので。渡すようにしたPR出すのはありやなしや。 extension JSONDecoder.DateDecodingStrategy { @available(OSX, obsoleted: 10.11) static var iso8601 = JSONDecoder.DateDecodingStrategy.formatted({ let formatter = DateFormatter() formatter.calendar = Calendar(identifier: .iso8601) formatter.locale = Locale(identifier: "en_US_POSIX") formatter.dateFormat = "yyyy'-'MM'-'dd'T'HH':'mm':'ss'Z'" formatter.timeZone = TimeZone(secondsFromGMT: 0) return formatter }()) } とかやってみたけど、候補を探すときに@availableを考慮してくれなくてダメだった。 Compile Swift Module 'Foo' (1 sources) /Users/norio/github/Foo/Sources/Foo/Foo.swift:17:37: error: ambiguous use of 'iso8601' decoder.dateDecodingStrategy = .iso8601 ^ Foundation.JSONDecoder:7:14: note: found this candidate case iso8601 ^ /Users/norio/github/Foo/Sources/Foo/Foo.swift:5:16: note: found this candidate static var iso8601 = JSONDecoder.DateDecodingStrategy.formatted({ ^
1swift-DEVELOPMENT-SNAPSHOT-2018-10-01-aでswift run --replが出来る様になりました。 https://github.com/apple/swift-package-manager/pull/1793 swift test --parallel --xunit-output result.xmlとか出来る様になってたの知らなかった。 https://github.com/apple/swift-package-manager/commit/047df6464ab15e27ab19b9a8263caeaf32127065 
master にも swift-5.0-branch にも PackageDescriptionV5.md がない？ https://github.com/apple/swift-package-manager/tree/swift-5.0-branch/Documentation 
2 module.modulemapを生成して、それ経由でリンクしていたはずです。 https://github.com/apple/swift-package-manager/pull/1406 
. ├── Package.swift └── Sources ├── App │ └── main.swift ├── ClibB │ ├── Greeting.cpp │ └── include │ └── Greeting.hpp └── ClibBWrapper ├── HelloCpp.mm └── include └── HelloCpp.h １つのPackage.swiftでやると、 ^ C++のコードをObjC++でラップしたモジュールを使うSwiftのパッケージ構成はこんな感じで、 Package.swiftは // swift-tools-version:4.0 import PackageDescription let package = Package( name: "Hello", targets: [.target(name: "App", dependencies:["ClibBWrapper"]), .target(name: "ClibBWrapper", dependencies:["ClibB"]), .target(name: "ClibB"),] ) こう。
1
// swift-tools-version:5.0 import PackageDescription let package = Package( name: "Foo", products: [ .library(name: "Foo", targets: ["Foo"]), .library(name: "CFoo", targets: ["CFoo"]) ], targets: [ .target(name: "Foo", swiftSettings: [ .unsafeFlags(["-emit-objc-header-path", "Sources/CFoo/include/Foo-swift.h"]) ]), .target(name: "CFoo", dependencies: ["Foo"]) ] ) とか。
2
unsafeFlagsが有効になる様にするとか。
1
--enable-test-discoveryオプションつけるとLinux用のテストファイルを自動生成する？機能が使えるらしい。良さそう https://github.com/apple/swift-package-manager/pull/2174/ 
1
Package.swift内で使えなくしたみたいですね。意図せずXcode 11で使えていたのかと。 https://github.com/apple/swift-package-manager/pull/2206 
1
headerSearchPathの話が出てた。 https://forums.swift.org/t/build-setting-headersearchpath-contains-invalid-component-s-srcroot/27960
1.systemLibrary を使う方法があることを知りました。Package.swift の target の中に .systemLibrary(name: "Choge") を入れておいて，Source/Choge/ 下に module.modulemap ファイルを module Choge [system] { header "/usr/local/include/hoge.h" link "hoge" export * } のようにしておくと、他の target で dependencies に Choge を入れておくだけで import して使えるようになります（みなさんもうとっくに知ってた話かな？） ただ（標準の library search path に入っていない？）ライブラリをリンクをするには linkerSettings: [ .unsafeFlags(["-L/usr/local/lib"]), .linkedLibrary("hoge") ] のようにしなきゃいけなくて、この unsafeFlag がどうにかならんもんかと思っています… CLI で swift run するだけなら export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/usr/local/lib をするだけで library search path に追加してくれるようなのですが、Xcode にはこの設定が反映されないようです 
2 3 2 
@package(url: "https://github.com/jpsim/Yams.git", from: "2.0.0") import Yams 
swift-5.1.5-RELEASE タグが付け直されて、OSSツールチェインも更新されてた。 https://github.com/apple/swift-package-manager/releases/tag/swift-5.1.5-RELEASE swift/utils/update_checkout/update-checkout-config.jsonにYamsのチェックアウト情報が載る様になってると気づいて調べたら、SwiftPMで--use-integrated-swift-driverオプションとか使える様になってたのね。 https://github.com/apple/swift-package-manager/pull/2736 
1 1
1
1
A replacement for the standard Mac app About dialog. - DangerCove/DCOAboutWindow
の、SPMがResources対応してるなら、それを使っても動くはずだけど、Xcode 12b3で対応してるのかどうかちょっとわかってない。 
1
name については言及されてませんでした https://github.com/apple/swift-package-manager/blob/main/Documentation/PackageDescription.md 
1
swift-format は公式のToolchainには入っていないのでまだ PATH に自前インストールしておく必要があるんですね。 
struct CounterApp: App { var body: some Scene { WindowGroup("Counter Demo") { Counter(count: 5, limit: 15) } } } // @main attribute is not supported in SwiftPM apps. // See https://bugs.swift.org/browse/SR-12683 for more details. CounterApp.main()
swift build --arch x86_64 --arch arm64とするとSwiftPMはユニバーサルバイナリを生成する。 clangの呼び出しを乗っ取ってclangへ-march=nehalemオプションを渡す仕組みが入ってる。しかし--arch arm64のオブジェクトファイル生成時にも渡されてしまい、-march=nehalemがサポートされてないオプションとしてエラーとなる。 https://github.com/Homebrew/homebrew-core/pull/66918
1
色々とアドバイスありがとうございました
https://github.com/taketo1024/swm-homology/blob/83c1a71dedab5183c69ddb45d5985a9e1359d8c2/Package.swift#L31-L42
// NG products: [ .library( name: "MyView", type: .static, targets: ["MyView"] ), ] // OK products: [ .library( name: "Preview", type: .dynamic, targets: ["MyView", "MyView2"] ), .library( name: "App", type: .static, targets: ["App"] ), ], A2. Bundle.moduleの生成されたコードが、Previewの場合にはBundleが生成されずにFatalErrorに落ちる不具合がある。 https://forums.swift.org/t/swiftui-previewer-crashes-while-in-swift-package-that-depends-on-anothers-packages-bundle-module-reference/41736 Bundle.moduleは利用せずに自前でBundleのextensionを書く。辛いけど仕方ない。 
1
1
.module 指定でPreviewできない件、自分もハマったのでまとめました。特にココでの議論から進展はないのですが、実は他の解決方法とか新情報がありましたら教えていただけると嬉しいです https://fromatom.hatenablog.com/entry/2022/01/03/180148
3
swift run でコマンドラインツールを走らせたときに SIGINT で止まらなくなって困っていたんですが，意外と Jira でも Forums でも Pull requests でもそれらしい言及がなかったので原因を探って PR を出してみました．困っている人は本当に困っていそうな問題なので共有してみます． 理解が間違っているところとかがあればご指摘いただけると嬉しいです． https://github.com/apple/swift-package-manager/pull/4224
3
swift run でコマンドラインツールを走らせたときに SIGINT で止まらなくなって困っていたんですが，意外と Jira でも Forums でも Pull requests でもそれらしい言及がなかったので原因を探って PR を出してみました．困っている人は本当に困っていそうな問題なので共有してみます． 理解が間違っているところとかがあればご指摘いただけると嬉しいです． https://github.com/apple/swift-package-manager/pull/4224 
8
Showing Recent Issues The operation couldn’t be completed. (SwiftPM.SPMRepositoryError error 5.) 特定のパッケージを更新して Package.swift を resolve しようとすると発生しました。 詳細は以下のスレッドに載せています。 https://twitter.com/the_uhooi/status/1505577290444713989?s=20&t=OtpKypkRTqgGV1873rtONA
https://t.co/54BMg6qpOO
ローカルで↑の内容を試してみます。
~/Library/Developer/Xcode/DerivedData ディレクトリを消したら直りました。
.build フォルダなどを削除して resolve し直したら直りました。
cause でチェーンして示すというのがいいんでしょうね。すべてが型付けされていれば、最上位レイヤーで起こり得るエラーが（ cause も含めて）型で洗い出すことが可能になり、そこからユーザーが必要になる粒度に応じてエラーメッセージを提供するみたいな。めっちゃ実装面倒ですが。 Swift の Forums でも、仮に Typed Throws を採用しても、複数のエラー型を列挙できるようにはしないという話がされていて、おそらくその理由は各レイヤーでそれらの粒度に応じてエラーを包み直すのが望ましいからかと。
.upToNextMajor → from: (前からあった) .branch → branch:
.revision → revision: の対応があるんだけど、 .upToNextMinor の対応が存在しなくて、コメントからするとそれが exact: に見える で .exact の対応してそうな exact: は消えた？ .exact の非推奨コメントに自分も遭遇しました。 Xcode13.3を境に .exact -> exact: になったのですね！ （新しい方のドキュメントの概要欄は、未記載の状態のようですが...。）
.exact の非推奨コメントに自分も遭遇しました。 Xcode13.3を境に .exact -> exact: になったのですね！ （新しい方のドキュメントの概要欄は、未記載の状態のようですが...。） exact: のコメントの文章はおかしいままですか？ドキュメントには出力されてないんですねw 1
:exact だけでなく、 :from のコメントも同じくおかしいぽいです。おんなじコピペコメントでした。
1
.exact は exact: に変わるけど、 .upToNextMinor はそのまま使える。 現状の依存関係のバージョンの書き方、まとめてみました↓ 【SwiftPM】依存関係のバージョンの書き方 https://qiita.com/m_rn/items/ef14be6e66d278830e7e
2
exact: とかのAPI変更ってプロポーザルあるんだっけ @d_date 知ってる？ 
.upToNextMinor を使うのは非推奨にならない…のでしょうか？ .package(url: String, "1.2.0"..<"1.3.0") のように範囲指定するのが推奨になるのかなぁと思っていました。 ref: https://developer.apple.com/documentation/swift_packages/package/dependency/requirement/2878234-uptonextminor 自分のイメージ↓ // Before .package(url: String, .branch("release/5.6")) .package(url: String, .revision("e74b07278b926c9ec6f9643455ea00d1ce04a021")) .package(url: String, .exact("1.2.0")) .package(url: String, .upToNextMajor(from: "1.2.0")) .package(url: String, .upToNextMinor(from: "1.2.0")) // After .package(url: String, branch: "release/5.6") .package(url: String, revision: "e74b07278b926c9ec6f9643455ea00d1ce04a021") .package(url: String, exact: "1.2.0") .package(url: String, from: "1.2.0") // `.package(url: String, "1.2.0"..<"2.0.0")` と同義 .package(url: String, "1.2.0"..<"1.3.0") ref: https://github.com/uhooi/mobile-app-trends/blob/main/2021/2021_4q.md#56リリース-0223
.upToNextMinor を使うのは非推奨にならない…のでしょうか？ .package(url: String, "1.2.0"..<"1.3.0") のように範囲指定するのが推奨になるのかなぁと思っていました。 ref: https://developer.apple.com/documentation/swift_packages/package/dependency/requirement/2878234-uptonextminor 自分のイメージ↓ // Before .package(url: String, .branch("release/5.6")) .package(url: String, .revision("e74b07278b926c9ec6f9643455ea00d1ce04a021")) .package(url: String, .exact("1.2.0")) .package(url: String, .upToNextMajor(from: "1.2.0")) .package(url: String, .upToNextMinor(from: "1.2.0")) // After .package(url: String, branch: "release/5.6") .package(url: String, revision: "e74b07278b926c9ec6f9643455ea00d1ce04a021") .package(url: String, exact: "1.2.0") .package(url: String, from: "1.2.0") // `.package(url: String, "1.2.0"..<"2.0.0")` と同義 .package(url: String, "1.2.0"..<"1.3.0") ref: https://github.com/uhooi/mobile-app-trends/blob/main/2021/2021_4q.md#56リリース-0223 .upToNextMinor は非推奨にならないです。 元々あった Package.Dependency.Requirement を返す .upToNextMinor は deprecated 指定されているんですが、 それとは別に新しく Range<Version> を返す .upToNextMinor が追加されるのです。 コードはここです。(Appleのドキュメントだとどこにあるかはわからなかったです) https://github.com/apple/swift-package-manager/blob/e25a590dc455baa430f2ec97eacc30257c172be2/Sources/PackageDescription/PackageRequirement.swift#L219 それが https://discord.com/channels/291054398077927425/304939011904897024/948065337448996955 で書いている事です。 つまり、 .upToNextMinor と書いたときに これまでは Package.Dependency.Requirement.upToNextMinor と解釈されていたのが、 これからは Range<Version>.upToNextMinor と解釈される、という事です。
2
.upToNextMinor は非推奨にならないです。 元々あった Package.Dependency.Requirement を返す .upToNextMinor は deprecated 指定されているんですが、 それとは別に新しく Range<Version> を返す .upToNextMinor が追加されるのです。 コードはここです。(Appleのドキュメントだとどこにあるかはわからなかったです) https://github.com/apple/swift-package-manager/blob/e25a590dc455baa430f2ec97eacc30257c172be2/Sources/PackageDescription/PackageRequirement.swift#L219 それが https://discord.com/channels/291054398077927425/304939011904897024/948065337448996955 で書いている事です。 つまり、 .upToNextMinor と書いたときに これまでは Package.Dependency.Requirement.upToNextMinor と解釈されていたのが、 これからは Range<Version>.upToNextMinor と解釈される、という事です。 （自分の他にも勘違いしている人多そう）
1
1 1
1
Products/Example.app をShow Finderして、 Example.app パッケージをShow Contentsして Frameworks フォルダからMLKitFaceDetection.framework と MLKitBarcodeScanning.framework を削除します。 （他の人にもわかるように手順を書いています。） 
1
2
1
3
$HOME/Library/org.swift.swiftpm/security を削除する必要がある。 13.1.4-beta1 ではなく . を挟んで 3.1.4-beta.1 にしておかないと、 beta 9 と beta 10 の順序がおかしくなってしまうので要注意です。 1
1
1
1
1 1
1
2 1
1
1
BuildConfiguration が struct なのにプロパティを let にしてるのが無意味でイケてないと僕は思っています。実際にここでやっているように、setterを外部から実装可能なので、結局書き込み禁止できてないからです。最初からvarで良かったのです。 で、こういうextensionはその型に対する汎用的なもので、このファイル固有の目的で必要なものというわけではないので、 他の場所からも見えて良いと思うのです。 ただ定義するファイルがここだと不適切かなと思っています。 
@inlinableとか駆使してるライブラリがビルドできなくて扱いづらい
1 1
MODULEMAP_FILE_CONTENT というパラメータに文字列をいれてやる方法を使っているので、 (2)で持ってる自前のモジュールマップ生成結果を このパラメータに上書きしてやれば、統合できると思います。 生成先のパスも MODULEMAP_PATH かなんかで指定されているので変更できる。 問題があるケースというのもそれでうまく解決すると思う。 
swift build とかしたい時が多々あって… 1
swift build で iOS 向けにビルドすることもできるようになりそうな気がしてます． 実際にそれを試してみた PoC リポジトリが以下にありますし． https://forums.swift.org/t/introducing-an-sdk-for-building-ios-macos-apps-on-linux-experimental/66233
2
.framework の組み立てを自前でやるのはわかるけど、 PIF(xcbuild)の利用は続いてるみたいで、 PIFの加工は減ったけど無くなってはないみたいで、 結局元PIFの役割はどこまで残ってるのかが知りたい あと、元々それだとビルドできないから加工してたという認識だけど、 なぜ加工を減らしても大丈夫なの？ 
.framework の組み立てを自前でやるのはわかるけど、 PIF(xcbuild)の利用は続いてるみたいで、 PIFの加工は減ったけど無くなってはないみたいで、 結局元PIFの役割はどこまで残ってるのかが知りたい あと、元々それだとビルドできないから加工してたという認識だけど、 なぜ加工を減らしても大丈夫なの？
1LC_BUILD_VERSION が存在してるかチェックするのが良いかな？
3
-set-build-version <platform> <minos> <sdk> という意味になってて、platformの2はiphoneos、7がiphoneos-simulatorです
