swift-developers-japan

swift-package-manager - The Package Manager for the Swift Programming Language

5:33 AM

それの構成を真似してmodule.modulemapを作りました。

@moaible 僕もハマったのですが、 https://github.com/apple/swift-evolution/blob/master/proposals/0158-package-manager-manifest-api-redesign.md#example-manifests を見て、解決しました。初見殺しですよね、特に3時代に使っていた場合なかなか気づけないです(　´･‿･｀)

swift-evolution - This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.

@mono おお...情報ありがとうございますproposalの方にあるんですね、結構探したと思ったんですが気づきませんでしたorz ~~READMEにリンクでもあるとハマる人が減りそうな気もしました（正式リリースしてから整備かな？）~~ と思ったらここに詳細ありました

https://github.com/apple/swift-package-manager/blob/swift-4.0-branch/Documentation/PackageDescriptionV4.md (edited)

https://github.com/apple/swift-package-manager/blob/750c36fcb96a5e25d620fa8ce70bcbd3ca25f086/Sources/Commands/SwiftTool.swift#L392

swift-package-manager - The Package Manager for the Swift Programming Language

1

llbuildの動画を見た

3:22 AM

swift-package-manager - The Package Manager for the Swift Programming Language

3:23 AM

SwiftPMはここらへんのコードで

3:23 AM

SPMのグラフ構造をllbuildへの入力に変換して

3:24 AM

https://github.com/apple/swift-package-manager/blob/750c36fcb96a5e25d620fa8ce70bcbd3ca25f086/Sources/Commands/SwiftTool.swift#L419 llbuildをコマンドとして実行してビルドさせてるっぽい

https://github.com/apple/swift-evolution/blob/master/proposals/0181-package-manager-cpp-language-version.md

swift-package-manager - The Package Manager for the Swift Programming Language

SwiftPMはllbuildを直接叩いてるけど、Xcode 9のnew build systemだと、中間にxcbuildというXPCのプロセスがいて、そこ経由でllbuildを使ってるそうです

そのxcbuildというのはfacebook製のxcbuildとは別物ですよね？

12:54 PM

名前被っちゃったのか

別物です、どっちが先なのかは誰も分からなさそうw

なんでプロセス分けてるんだろう IDEとしてのxcodeがよくバグるから、クラッシュ巻き込まれないようにしたのかな

swift-evolution - This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.

お

どんどん Package の引数が増えると、順番わからなくなってしまう。 let package = Package() package.name = "FooBar" package.products = [...] みたいに書いていった方が楽かもしれん。

そうですね

引数がタプルモデルを止めたんだったら引数の順番変えられるようにしてもいいかもですね。せっかくラベルあるんだし。

なんかこれだけじゃ仕様としていろいろ足りない気がするけど

1:38 AM

C++も clang module system を前提にするのかな

https://github.com/apple/swift-evolution/blob/master/proposals/0060-defaulted-parameter-order.md を revert するのはハードル高いっすねぇ。

[Xcodeproj] Add dummy target to provide autocomplete in the manifest … by aciidb0mb3r · Pull Request #1266 · apple/swift-package-manager

swift-evolution - This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.

@koher は何が気になってcpp buildのリンクをはったんですか？

気になったというか、レビュー入りしたからです。

1:41 AM

@omochimetaru が気になりそうな話題だと思って。 (edited)

ほんとうだ July11...14

1:41 AM

Once we get the build settings feature, we will deprecate these properties.

1:42 AM

これって、ビルドセッティング機能を後に足したときに、この提案で足してる cStandard を削除する

1:42 AM

って意味なんですかね

"build settings feature" って何だろう？

いま全く0機能なのを0.2ぐらいとりあえずつなぎで入れる、って感じがする

1:42 AM

@rintaro xcodeの build settings とかでやるような、いろんなビルドオプションを設定する機能のことかと想像しました

1

[swift-evolution-announce] Swift 4 Package Manager Roadmap https://lists.swift.org/pipermail/swift-evolution-announce/2017-January/000307.html

1:47 AM

^に – Support Build Settings ってのも書かれてる。

– Support Build Settings The package manager has no way to provide specific settings, such as compiler flags, for building the targets in a package. Some settings are critical for production code, such as the "deployment target" (the minimum OS version that the built code will run on). We need to provide a way to set at least the most important settings which users will need control over.

いま全く0機能なのを0.2ぐらいとりあえずつなぎで入れる、って感じがする

ですね。

1

ぉ

どんどん Package の引数が増えると、順番わからなくなってしまう。

PackageDescription.PackageをCodable対応にして、Package.swiftへエンコードするEncoderを作る… (edited)

それだと環境でパラメータを分岐したりできない

PlaygroundでPackageDescriptionをインポートできる様にして、雛形を作る的なイメージ。

あ〜 , jsonじゃなくて、初期状態用の .swift を吐くんですね。

1:52 AM

そこから編集開始すると

ちょっとSwiftPMのSlackへ妄想を垂れ流してくるかな。

1

1:59 AM

書いて来た

Hi, We have an unofficial slack team to aid the development of Swift Package Manager. All the major discussion happens on the mailing list but it is useful to have a quick communication channel to discuss something small or to bounce off some random ideas. You can get an invite to join the slack team by entering your email id here: https://swift-package-manager.herokuapp.com/ Team ID: http://swiftpm.slack.com More info on slack: https://slack.com -- Ankit

2:00 AM

ここですか？

そそ

とりあえず「PlaygroundでPackageDescriptionをインポートできるといいね！」ってことで要望を出しておいた。 http://www.openradar.me/radar?id=5057232672653312

https://github.com/apple/swift-package-manager/pull/1266 Xcode で Package.swift のコード補完が実現

…file

5

これ毎回ググりながら書いてたんですけど他の人はどうしてるんだろうと思ってました。

ググりながら書いてますね

9:53 AM

swift buildしたらとりあえずコンパイルエラー出るから直感でやってたりもする

SPMのライブラリにCのモジュールが入ってるのですが、非SPMでの利用のためgenerate-xcodeprojで作ったxcodeprojをそのままリポジトリに入れました。 carthageでframeworkを作るとCモジュールのフレームワークにヘッダやmodulemapが入っておらず、読み込めないものができていました。

12:59 PM

更にxcodeprojの設定を

Build Settings -> Defines ModuleをYES
Build Settings -> Module Map Fileにパス記述
Build Phases -> Headersを追加

でそれらが含まれた状態のものまでは作れたのですが、出力されたフレームワークのmodulemapは元のものそのままになっており、正常に読み込むには更にmoduleをframework moduleに書き換える必要があるようです。

12:59 PM

Frameworkの中身まで書き換えるのはユーザーフレンドリーでないし、 xcodeprojの再生成もたびたびするのでうまいxcodeprojを作ってくれるとありがたいのですが何か方法はないでしょうか。

1:00 PM

今のところのブランチ https://github.com/t-ae/xorswift/tree/xcproj

t-ae/xorswift

xorswift - Xorshift pseudorandom number generator library for Swift.

それって、SPMとしてビルドするときは、Cモジュールの部分はFrameworkにはなってないって事？

1:12 PM

Swiftモジュール側からはmodulemap定義にもとづいてimportできるけど

そこがよくわかんないんですよね

1:13 PM

xcodeprojのProductsにはFrameworkがでてるんですが

1:13 PM

あ、忘れてましたけど

1:14 PM

generate-xcodeprojで作ったらHeader search pathが勝手に追加されてます

SPM的にはCターゲットは別にFrameworkじゃないんじゃないかなあ

1:14 PM

SPMの下回りはllbuildで

1:14 PM

llbuildはllvmファミリだから、modulemapのシステムはあるけど

上で書いた欠けてるFrameworkもsearch path追加したら読み込めました

1:15 PM

swift buildだとdylibができますしね

これビルドするにはどんなコマンド打てばいいの

swift buildでいけるはず

ああ、packageつけないのか。

1:16 PM

まちがえてた

ｗ

1:17 PM

cleanだとつくし微妙にややこしいですね

$ swift build -v で

1:18 PM

ローレベルで叩いてるコマンドがダンプされる

そっちはdylibができますよね？

だね

1:19 PM

libCxorswift.dylib

1:19 PM

をつくって

carthage対応するには結局xcodeprojをおいてFrameworkをちゃんと作れる状態にする必要があるようなので

swift側では、 Cxorswift/includeにパス通して

1:20 PM

Cxcorsiwft/include/module.mapを読み込ませてるね

そうなってますね。

だからやっぱSPMレベルではCバイナリ+ヘッダ+modulemapで

1:21 PM

swiftとつなぎこんでるから・・・

xcodeだとtouch frameworkがあるんで別の方法になってますね

are?

1:22 PM

generate-xcodeprojして開いてビルドしたら

1:22 PM

ビルドはできたよ。

それはできます。

Carthage対応がだめってことか。

その中で使う分には問題ないんですが carthageとかで外で使おうとするとheader search path追加なりなんなりが必要になってしまう

carthageの問題なのでは

iOSで使うんじゃなければCarthage対応いらないんじゃない？

自分だったらめんどくさくなってCarthage用のxcodeprojは完全に手動で別途保守しそう

1:24 PM

ディレクトリ構造的に共存できないとか？

generate-xcodeprojした直後にビルドできるframeworkの時点でHeaders, Modulesが欠けてますからねぇ

1:25 PM

さっき貼ったブランチは設定書き換え済みでHeaders, Modulesが生成されるところまでいってます。

1:27 PM

設定書き換えるのがめんどくさいのはともかくcarthage用のmodulemapをおいておいてそれを指定すればなんとかなりそうな気がしてきました。

generate-xcodeprojはべき等に保ちたくない？

設定周りも--xcconfig-overridesオプションつかえばいけるのかな

1:28 PM

--xcconfig-overridesで設定はいじれるらしいです

--xcconfig-overrides Path to xcconfig file

1:28 PM

おお！

1:28 PM

これはよさそう

carthageのほう掘ってて知りました

xcconfigファイルをおいておいて、それを指定して生成するようにして

1:28 PM

生成コマンドはシェルスクリプトおいておけば

1:28 PM

べき等にできそうだ

numswで議論してたのもこれで行けそうですよね

1:29 PM

ビルドスクリプトとかまでかけるかは確かめてないですが

あーxcconfigにはそれは書けない気もする

やっぱりそんな気しますよね

1:30 PM

Build phasesが書けないならヘッダコピーが書けないのでだめそうだ

1:33 PM

出力してみましたがそれに当たるものはなさそうですね。

出力とは？

xcodebuild -scheme "schemeName" -showBuildSettings >> mynew.xcconfig

1:33 PM

全部出てるか知らないですが

あー既存からダンプできるんだ

一回生成してxcodeでいじって次生成するときは同じのをつかうみたいなのは簡単にできそうですね

xcodeprojの再生成もたびたびするのでうまいxcodeprojを作ってくれるとありがたいのですが何か方法はないでしょうか。

Cのモジュールを含む場合、再生成は全くお勧めできないかな。 (edited)

Xcodeの場合CとSwiftを同じターゲットに含められるので、一つのターゲットにするべき。

xcprojは自前で作って持っておくってことですね

6:11 AM

carthageのほうでswiftpm対応のためxcodeprojを勝手に生成するみたいなプルリクが出てるんですがこっちのほうでは問題になりそうな

6:15 AM

問題としては、swiftpmでCモジュールへのdependenciesを持っているものすべてについて carthage対応しようとしたときに同じ対応が必要になることなんですが (edited)

そもそもの疑問として、生成したxcodeprojが欠けたフレームワークを作ってそれをHeader Search Pathで補っている現状が正しいのかというのもあります。

一つのターゲットへの変更はこんな感じ。 https://github.com/t-ae/xorswift/compare/xcproj...norio-nomura:single-target-xcodeproj

t-ae/xorswift

xorswift - Xorshift pseudorandom number generator library for Swift.

7:50 AM

Sources/Cxorswift/include/Cxorswift.h を追加することで Sources/Cxorswift/include/module.modulemap を削除したりもしてる。

そこ自動生成したxcodeprojだと絶対パス入りのmodulemapができちゃうんですよね

module.modulemap は使わない様に変えました。

生成物も一つのフレームワークになって良いですね。なんでSPMがこれをしてくれないのか……

xorswift.h はフレームワークのXorswift.hとかぶるので、xorshift.h xorshift.cpp へ名前を変えました。

7:56 AM

SwiftPMのXcode project生成は、ターゲットとかもSwiftPMの依存関係を再現することにこだわってるみたいですね。

7:58 AM

XcodeのClangターゲットは module.modulemap を自動で生成する機能を持ってるので、SwiftPMもそれを活かす様にしてくれれば良いのですが、活かしてくれず。

単純に日が浅い＋Cでの利用者がいないせいかもですね。検索してもシステムモジュールの話ばっかりですし。

8:05 AM

先にCで書いたので速度が気になったのですが当分は全部swiftにしとくとかが楽な気がしてきました。

ループアンローリングする前に測ったらswiftだと二倍近くかかってたのにいまの実装だと40%増くらいに収まっている……

8:14 AM

とりあえず純swiftにしておこうと思います。ありがとうございました。

@t.ae Swiftの方が遅い理由ってどのあたりなんだろう？

ループのみにしたらswiftとcで同程度でした。 xor, shiftの部分だと思います。ループアンローリングでの性能悪化が軽減されてるのはよくわかんないですね。

SwiftPMによって生成されたxcodeprojにSWIFT_ACTIVE_COMPILATION_CONDITIONS = SWIFT_PACKAGEと設定されているのが疑問に思いAnkitさんに聞いてみたら、swift package generate-xcodeprojはswift buildによるビルドをXcodeで再現するために存在するためらしい。

11:39 AM

汎用的なxcodeprojを作るのは目的に含まれていないため現在の挙動になっている。

なるほど

汎用的なxcodeprojを作るコマンドを追加してしまうべきだな。

↓って情報が古いままだったりします？ https://swift.org/package-manager/#example-usage

https://github.com/apple/swift-package-manager/blob/master/Documentation/PackageDescriptionV4.md

Swift is a general-purpose programming language built using a modern approach to safety, performance, and software design patterns.

3の書き方(4でも動く)ぽいですね

SwiftPM関連のProposalいっぱいあるんですが、Swift4時点の使い方の情報でまとまったものってありますか？swift-package-managerリポジトリを見ればいいんでしょうか？

9:40 AM

お、そうなんですね。

9:40 AM

swift-package-manager - The Package Manager for the Swift Programming Language

9:40 AM

これとか？

ソース見るのが手っ取り早かったです(　´･‿･｀)

1

それですね

お、ありがとうございます。

Proposal追っても、その時点から微妙に変更あってそのままでは動かなかったり(　´･‿･｀)

そういえば、 SwiftPM じゃないですが、新しい Range 関連で UnboundRange が Proposal のどこにもない（ようだ）という話を @rintaro さんに聞きました。

9:43 AM

とりあえず↑のドキュメント見てやってみます。

僕は、主に4の雛形作ってどう変わったのか観察しつつ、細かいところはソース覗きました。

なるほど。それが一番確実ではありますね。

9:45 AM

これだけみんなが使うツールとしては間違えてる感がありますが

今ちらっと上のドキュメント見ましたが、僕が気になったところは追従してましたし、信用できそうです

tool version周りの話 https://github.com/apple/swift-evolution/blob/master/proposals/0152-package-manager-tools-version.md

Swift Package Manager (SwiftPM) Version 4 概要 - Qiita

swift-evolution - This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.

1

@mono おお、よかったです。

これも良かったです。当時としては正確そうですが、微妙に書き方違うところあります。 https://qiita.com/jpmartha/items/948a86bbb7d3e9240ce4

この記事は、Swift Package Manager (以下 SwiftPM) の Version 3 から 4 への変更内容をまとめたものです。有効に活用するためにはさらに掘り下げていきたいところですが、この記事では概要にとど...

ありがとうございます。

9:51 AM

↓の dev が気になってるんですが、ちゃんとインストールできてないでしょうか？ $ swift package --version Apple Swift Package Manager - Swift 4.0.0-dev (swiftpm-13126)

どうなんだろうXcode9環境に戻ったら確認して見ます。

1

Apple Swift Package Manager - Swift 4.0.0-dev (swiftpm-13126) 同じく。

僕は川にいるので家に戻ったら調べます

…と打ってたら、みんなそれっぽいですね(　´･‿･｀)

Observableの隠語と認識してしまった、リアル川のほうですね?

Observableの隠語ｗｗ

多摩川です

Observable<多摩>

2

みんな川好き

https://github.com/apple/swift-package-manager/blob/b3074523e1e3a4c280829a1f5af6e4c9d3543714/Sources/Utility/Versioning.swift#L83-L85 isDevelopment が取れたコミットは swift-4.0-branch にもないので、忘れ去られているだけなのかと。

swift-package-manager - The Package Manager for the Swift Programming Language

PRチャンス

同じでした

➜ ~ swift package --version Apple Swift Package Manager - Swift 4.0.0-dev (swiftpm-13126) # ついでに ➜ ~ DEVELOPER_DIR=/Applications/Xcode-8.3.app/Contents/Developer swift package --version Apple Swift Package Manager - Swift 3.1.0 (swiftpm-12084)

その後、みなさんのおかげで無事対応できました

1

3:02 AM

Swift 3 の頃のシンプルな Package.swift 好きだったんですけどねぇ・・・。↓ swift package init で生成されるテンプレート。 BEFORE import PackageDescription let package = Package( name: "Swiftor" ) AFTER

// swift-tools-version:4.0 // The swift-tools-version declares the minimum version of Swift required to build this package. import PackageDescription let package = Package( name: "Swiftor", products: [ // Products define the executables and libraries produced by a package, and make them visible to other packages. .library( name: "Swiftor", targets: ["Swiftor"]), ], dependencies: [ // Dependencies declare other packages that this package depends on. // .package(url: /* package url */, from: "1.0.0"), ], targets: [ // Targets are the basic building blocks of a package. A target can define a module or a test suite. // Targets can depend on other targets in this package, and on products in packages which this package depends on. .target( name: "Swiftor", dependencies: []), .testTarget( name: "SwiftorTests", dependencies: ["Swiftor"]), ] )

すべて明示する感じになりましたよね。

3:04 AM

3の時にexcludeで弾いてた場合だと、書き方変わっただけで記述量大差無いですね。 (edited)

はい。 targets 省略でも、デフォルトとして解釈してくれてもいい気がするんですけどねぇ・・・。

3:06 AM

まあ、自動生成なんでいいんですが、初見でも何の疑問もなく理解できる BEFORE は好きでした。

1

Package.resolved を更新したくて carthage update 相当のことをするにはどうすればいいんだと思って↓見たらまだ pinning とか書いてあってがっかりしてたけど普通に swift package update でできた。 https://github.com/apple/swift-package-manager/blob/master/Documentation/Usage.md

https://bugs.swift.org/browse/SR-6190

swift-package-manager - The Package Manager for the Swift Programming Language

$ rm Package.resolved でごまかして生きてる

ひどいｗ

掘り出し: https://twitter.com/_mono/status/901257788222914560

🐶 mono  (@_mono)

Swift Package Manager 4のマニフェストにマイグレーションdone(　´･‿･｀)ビルド中に詰まってしまい一旦断念してたけど、それも一緒に解消されたみたい(　´･‿･｀)

2

SwiftPMのgenerate-xcodeproj、Package.swiftについてのターゲットが作られて、そこで import PackageDescription を Cmd + Click すると

2:39 AM

Package.swiftに関わるクラス定義が見えるので

2:39 AM

書き方わかって便利と思ったけど

2:39 AM

extension Dependency { public static func target(name: String) -> PackageDescription.Target.Dependency public static func product(name: String, package: String? = default) -> PackageDescription.Target.Dependency public static func byName(name: String) -> PackageDescription.Target.Dependency }

2:39 AM

↑ PackageDescription.Target.Dependency となるべくところが Dependency になっていて

2:40 AM

PackageDescription.Package.Dependency も存在するのでよくわからなくなっている

2:41 AM

これってSpmは関係ないXcodeの型定義表示機能のバグかな

試そうとしたらimport PackageDescriptionで

Module compiled with Swift 4.0 cannot be imported in Swift 4.0.1: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/pm/4/PackageDescription.swiftmodule

って言われて定義をひらけなかった。

僕の環境は Version 9.0.1 (9A1004) + 同梱ツールチェイン　です

ああ、Xcode 9.1 betaだった。

な、なるほど

よくわかってないんですが、 canImport って SwiftPM で管理された二つの独立した（別リポジトリの）パッケージ間で利用することはできるんでしょうか？

5:37 AM

たとえば、 A, B, C の三つのパッケージがあって、 A に canImport(B) が書いてあって extension が生やされていて、 C が A と B の両方に依存している場合にはその extension が使えるけど、 A にしか依存していない場合はその extension が使えないとか。

5:38 AM

A がビルドできるためには canImport(B) とはいえ A が B に依存していないといけない気がしていて、そうすると常に canImport(B) が真になる気がします。 optional な dependency が記述できないと実現できなさそう。

swiftc的にはimport pathの中に置いてあるモジュール + システムパスを検索してるから、 SPMがCを解決したときに Bが入ってれば ABC 、なければ AC が検索パスに展開されて、そのもとで諸々がコンパイルされてうまくいきそうな気がする

A の Package.swift の dependencies はどうなる？

そこでは指定してないけどCのためにとってきたBを canImportのときには見つけるんじゃないかってアイデアだけど、

B に依存しないと canImport(B) の内部を解決する方法がないし、依存してるなら C も間接的に B に依存することになって常に canImport(B) が満たされそう。

それとも完全にPackage.swiftだけに依存して隔離されてビルドされてるんだろうか

5:42 AM

内部を解決するってどういう意味ですか？

5:42 AM

コンパイル時分岐だから、見つからないときは全部無視では。

A の Package.swift に一切 B の情報がないと、 A 単体で見たときにビルドできなくない？

5:43 AM

つまり、 A 単体では swift test でテストすることすらできないってこと？

単体で見たときに canImport(B) が false になるからその範囲のソースコードは無かったことになるってこと

それはさすがに辛くないかな？

5:43 AM

まあでもその仮定なら動作しそう。

え、でもいまも #if os(iOS) って

5:43 AM

そういう挙動ですよね

現実のオペレーション的には辛そうだけど。

5:44 AM

でも #if os(iOS) は OS を切り替えてテストできるけど

5:44 AM

#if canImport(B) はどうやっても A のリポジトリ単体でテストできなくなっちゃうよ。

5:44 AM

あーちがうか

5:44 AM

テストのターゲットに

5:44 AM

書けばできるのか。

Bがあるやつとないやつの２種類用意すればよさおすですね

A は B に依存しないけど、 A のテストを B に依存させればいいんだ。

Bが無かった場合にコンパイルが通るかのテストは別途必要ですね

まあテストパッケージが二つでもいいな。

#if canImport(B) の内部で書いたコードが、Bが無いときにも必要な関数が混ざっていたりする可能性がある

確かに。

SwiftPMのMLも受信するかあ・・・

ATests と ATestsWithB とかを作ればいいのかな。

そろそろややこしくなってきたし。

5:47 AM

are?

canImport の Proposal は swift-evolution に出てるよ

いえ、SwiftPMそれ自体の

5:47 AM

Slackなんでしたっけ。

SwiftPM の改変も swift-evolution に出てないっけ？

本当に全部出てんのかな

https://github.com/apple/swift-evolution/blob/master/proposals/0162-package-manager-custom-target-layouts.md

https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md

swift-evolution - This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.

5:48 AM

こういうのとか。

Package.swiftの記述に関するものは、全てswift-evolutionに出てる気がします。

なるほど

コマンドラインオプションとかの機能追加は、出ていないものもあるかと。

ふむふむ

swift runみたいなサブコマンド？レベルの追加は出てる。

ターゲットの記法が細かくなったやつとか swift runとかは

6:08 AM

プロポーザルは目を通してるから知ってたけど

6:08 AM

なんかわからない感じがあるんだよなあ

swift test --filter <test pattern>みたいなオプションとかはSlackとかで話されて追加されてる気がする。

なるほど。そういうのってswiftpm slackのgeneral?チャンネルですか？

ですね。

なるほど。ながめてみます。

canImportはswiftpmのSlackで話された形跡がないですね。

6:13 AM

誰もSwiftPMでのcanImportの運用について気づいて（気にして）ないんじゃないかな？ (edited)

古い Proposal はありますよね？

6:15 AM

https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md

swift-evolution - This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.

https://github.com/apple/swift-package-manager/pull/1388/files

swift-evolution - This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.

6:15 AM

Status: Implemented (Swift 4.1)

ああ、これ自体は SwiftPM と関係ないから

6:16 AM

SwiftPM 側で意識されてないという話なのか。

Package.swift内でcanImportを使う？というのも考えたけど、swift test -vの出力を見る限りPackage.swiftのパースでは最低限のimport pathしか設定されていない。

Package.swift 内で canImport 、なんかメタでヤバそうな感じだ・・・

SwiftPMのSlackで聞いてみるといいんじゃないかな…

canImport の実装読んでみても良さそうですね。 canImport 自体は SwiftPM と独立に動きそうなので、 canImport の厳密な判定条件がわかれば実際にどういう挙動をするのか理解できそうです。

↑のMLのスレ読んだけど誰もSPMの話ししてなかった

ちょっと議論追えてないですが、canImport 自体の評価はparse時なので、そのソースがコンパイルされるときに、検索パス上にそのモジュールがあればtrue、無ければfalseとして評価されるだけですよ。

なるほど。

じゃあ @omochimetaru の想定通りに動きそうな感じか。

C が A,B に依存していて、Aに canImport(B) が書いてあるとすると、 C のビルド時に A, B どちらが先にコンパイルされるかでAのコンパイル結果が変わったりするのか？という疑問があるけど、どうなんでしょうね。 (edited)

swift package generate-completion-script zsh > ~/.oh-my-zsh/custom/plugins/swift/_swiftしてzshがswiftのコマンドラインオプションを補完できる様にした。

$ swift build -- build sources into binary products package -- perform operations on Swift packages run -- build and run an executable product test -- build and run tests

(edited)

1

Use map instead of flatMap by moiseev · Pull Request #1388 · apple/swift-package-manager

3:40 AM

SwiftPMに気になるパッチが。無駄に flatMap にしちゃってる例のアレかこれ

String to Intっぽいですけどその場合Int?が返るのでflatMapが正しいのでは？

間違ってる、と思ったらすでにikesyoさんがコメントしてた。

あれ、、、本当だ・・・

swift build [1/1] Compile CYaml src/writer.c Compile CYaml src/reader.c Compile CYaml src/scanner.c Compile CYaml src/parser.c Compile CYaml src/emitter.c Compile CYaml src/api.c Compile Swift Module 'Yams' (15 sources) Compile Swift Module 'render0' (1 sources) Linking ./.build/x86_64-apple-macosx10.10/debug/render0 Fetching https://github.com/jpsim/Yams.git Cloning https://github.com/jpsim/Yams.git Resolving https://github.com/jpsim/Yams.git at 0.5.0 swift build end

12:52 PM

$ swift build のプロセス出力をリダイレクトしているだけなのに

12:52 PM

↑なぜか前後順が入れ替わる・・・

12:52 PM

SwiftPM内部で、 git を叩いたときと、コンパイラを叩いたときで、それらの出力を流したりキャプチャしたりしているからっぽいんだけど

12:53 PM

なんとかならないだろうか　SPMのソースも眺めたけどよくわからず

12:55 PM

https://github.com/apple/swift-package-manager/blob/c62bd0bb8c7669fd284e6e3b2fc82f9708334b4f/Sources/SourceControl/GitRepository.swift#L60 https://github.com/apple/swift-package-manager/blob/d92b3558e227504a79cb18b6033075c18e85d97e/Sources/Utility/Process.swift#L15 多分ここらへんだけど、これだと逆に何も出力されないように見えるからここじゃないっぽい

swift-package-manager - The Package Manager for the Swift Programming Language

https://github.com/apple/swift-package-manager/blob/c62bd0bb8c7669fd284e6e3b2fc82f9708334b4f/Sources/SourceControl/GitRepository.swift#L41

swift-package-manager - The Package Manager for the Swift Programming Language

12:57 PM

swift-package-manager - The Package Manager for the Swift Programming Language

12:57 PM

こっちかな

1:03 PM

$ touch a.txt $ tail -f a.txt $ swift build >> a.txt これだけでも再現した

この辺かな？ https://github.com/apple/swift-package-manager/blob/d92b3558e227504a79cb18b6033075c18e85d97e/Sources/Basic/Process.swift#L295

swift-package-manager - The Package Manager for the Swift Programming Language

そこらへんは見たんですけど

1:56 PM

Process クラスは、redirectOutput が true だと ↑のコードを使って

1:56 PM

サブプロセスのstdout と stderr をパイプにつなげた上で、

1:57 PM

それがcloseされるまでreadしつづけて、closeされた完全なバイト列を変数に保存するだけのスレッドを立ち上げて

1:57 PM

waitUntilExitメソッドではそのスレッドの完了をjoinで待つんですね

1:57 PM

なので、Processクラスが出力を捕まえることまではわかっているんですが

1:57 PM

gitのcloneやfetchの操作をするところでは

1:58 PM

それをラップしたcheckNonZeroExitメソッドを叩いて結果を捨てていて

1:58 PM

Processクラスが捕まえた結果を、 SwiftPM自体の出力として改めて流す処理が見当たらなくて

1:59 PM

読んだ範囲だとキャプチャするだけで出力してないので、現状の挙動とも一致しなくて謎です。

ここのfiledesの1と2がstdoutとstderrじゃない？ https://github.com/apple/swift-package-manager/blob/d92b3558e227504a79cb18b6033075c18e85d97e/Sources/Basic/Process.swift#L310-L311

How to redirect full output of git clone to a file?

swift-package-manager - The Package Manager for the Swift Programming Language

1と2はstdoutとstderrだから、そのelseのフローは、 subprocessのstdout/err を、呼び出し側のstdout / err につなげているのでは？

ああ、こっちを通らないのね。

checkNonZeroExitでもredirectOutput = true だし、 Processのコンストラクタもデフォルトで = true です

2:05 PM

（これがfalseになるフローを見つけられてない可能性もある

2:05 PM

あー、チェックアウトしてxcodeprojで開いたほうが良い気がしてきた。

これらはgitのメッセージなの？ Fetching https://github.com/jpsim/Yams.git Cloning https://github.com/jpsim/Yams.git

あ〜〜・・・そうじゃない可能性は考慮して↓の記事を見ていたけど、 https://stackoverflow.com/questions/37669115/how-to-redirect-full-output-of-git-clone-to-a-file よく見るとgitの出力と違う文字列ですね・・・

When I run git clone like usual, I see this: $ git clone https://github.com/bensmithett/webpack-css-example Cloning into 'webpack-css-example'... remote: Counting objects: 179, done. remote: Total...

2:10 PM

しまった、そういうことか。

2:11 PM

ありがとうございます

1

Swift.print()にバッファが効いてるのかな？>リダイレクトで入れ替わる。

SwiftPMのslackのhelp channelに投稿して寝たけど無視されて他の話題になっちゃったな・・・

あとはSwift.print()が出力先をflockしてるっぽいのも気になってるけど、再現実装が必要かな。

10:26 AM

スレッドサニタイザーの話題が継続してましたね>Slack

10:30 AM

再現実装書いたらコメントしたかったけど、明後日くらいまでは手を付けられないかな。

ふむふむ。見ていただいてありがとうございます。

SwiftPM SlackはankitさんがU.S.へ移動してから静かになってしまいましたね。

Ankitさんってめちゃめちゃコミットしてるけど、メイン？開発者なんですか？

3:26 AM

最近見始めたからよくわからないです

去年の8月にApple入って、一年インドでリモートでした。

ほほー　なるほど。

それ以前から積極的にコミットしてたけど、入社以降はメイン開発者な感じですね。

ankitさんが入ってなかったらSwiftPMは死んでたと思う。

SwiftPMが始まった頃、homebrewのMax HowellがAppleに引き抜かれて携わってたって聞いて

3:32 AM

そんな感じかと思ってました。

結構すぐ辞めちゃいましたからねー

3:34 AM

大企業はやっぱ合わなかったわ。的なツイートしてました。

へえ〜、そうだったんですね。

ankitさんインドにいた時は、タイムゾーンが近かったからSlackでリアルタイムに喋りやすかった。

3:56 AM

Apple社内とのコミュニケーションにもSlackが大きな部分を占めてて、それでレスポンスが良かったのだろうと想像。

swift buildで成果物が置かれるディレクトリのパスを取得: $ swift build --configuration release --show-bin-path /Users/norio/github/gysb/.build/x86_64-apple-macosx10.10/release

4:39 AM

Swift 4.0からパスにplatformも入る様になったので追加された。

SwiftPM Slackの#helpにコメント書いたよ。

5:39 AM

やっぱりバッファリングが問題で、SwiftPMがsetlinebuf(Darwin.stdout)をすると直る。> swift buildの出力をキャプチャすると順序が入れ替わる。 (edited)

おお、ありがとうございます！

6:07 AM

あとで確認します

とりあえず、setlinebuf()の利用自体が正しいのかはよくわかっていません。これについて、僕自身ではSwiftPMへPRを出すモチベーションは低いです。omochiさんのところで動作確認出来て、その気があるならPRを書かれると良いのではないかと思います。

なるほど。僕もunixパイプのバッファリング周りの振る舞いについてはちゃんとした知識がないので、ひとまずbugsの反応を待ちます。

SwiftLintとSourceKittenの次のリリースはSwiftPMで-Xswiftc -static-stdlibを使ってビルドしたバイナリになりそうです。 https://github.com/realm/SwiftLint/pull/1951 https://github.com/jpsim/SourceKitten/pull/443

Statically Linked Binary by norio-nomura · Pull Request #1951 · realm/SwiftLint

Use swift build --configuration release --static-swift-stdlib for building swiftlint

[WIP] Statically Linked Binary by norio-nomura · Pull Request #443 · jpsim/SourceKitten

Same as realm/SwiftLint#1951 This does not depends on #442 directly, but should be merged after that.

swift-buildをXcodeでデバッグ実行した時に"could not find llbuild"エラーになる不具合を修正しました。 https://bugs.swift.org/browse/SR-6371 (edited)

SwiftPMに0.1.0のバージョンタグがついて、Dependencyとして利用できる様になったぽい。https://github.com/apple/swift-package-manager/releases/tag/0.1.0

タグついてなかったのかｗ

A -> B -> C というような依存関係があって、 B -> C の依存がブランチで記述されていた場合に、 A を swift build したり swift package update したりするとエラーになるんですが、そういうものなのでしょうか？ B -> C のブランチによる依存とは、 B の Package.swift に↓ように書いた場合のことです。 .package(url: "https://github.com/foo/C.git", .branch("master"))

1:47 AM

↓のリポジトリを clone して swift package update するか、もしくは Package.resolved を削除および swift package reset してから swift build すると再現します。 A = swtws, B = TweetupKit, C = OAuthSwift です。 https://github.com/swift-tweets/swtws

swift-tweets/swtws

swtws - A command line tool for Swift Tweets

そういうものみたいです。SwiftLintでも同様のissueがありました。 https://github.com/realm/SwiftLint/issues/1962

Point SPM to versions of deps and not branches · Issue #1962 · realm/SwiftLint

New Issue Checklist Updated SwiftLint to the latest version I searched for existing GitHub issues Bug Report So I am trying to work on a SPM project using the SwiftLintFramework library and whe...

1

おお、そうするとライブラリには .branch は使えないですね・・・。使った瞬間に他のライブラリがそのライブラリに依存できなくなってしまう

AでBを使う時にswift package edit Bを使ったら、開発途中のBを使えませんかね？ (edited)

ダメっぽいですね・・・。もしかして .branch じゃなくて .revision なら大丈夫ですか？

あ、swift package edit Cでは？

2:45 AM

swtsだとswift package edit OAuthSwiftか

うーん、うまくいかなさそうな感じです。よくわからないのは、 Package.resolved を手で書き換えて（ swift package update ではなく） swift build してもうまくいかないことですね・・・。

2:55 AM

Package.resolved がある状態で swift build しても依存解決のための何かが実行されるんですっけ？？単に clone/fetch してビルドするだけかと思ってました。

2:58 AM

今、 TweetupKit の 0.2.1 と 0.2.2 で TweetupKit の中で依存する OAuthSwift の向き先がフォーク先からオリジナルに変わってるのもややこしいかもです。

やっぱりswift package edit Bだった。

$ git reset --hard HEAD is now at 66ed003 Update TweetupKit $ swift package edit TweetupKit Fetching https://github.com/swift-tweets/tweetup-kit.git Fetching https://github.com/swift-tweets/OAuthSwift.git Fetching https://github.com/kylef/Commander.git Fetching https://github.com/koher/PromiseK.git Fetching https://github.com/kylef/Spectre.git Cloning https://github.com/swift-tweets/tweetup-kit.git Resolving https://github.com/swift-tweets/tweetup-kit.git at 0.2.1 Cloning https://github.com/koher/PromiseK.git Resolving https://github.com/koher/PromiseK.git at 3.0.0-alpha.4 Cloning https://github.com/kylef/Spectre.git Resolving https://github.com/kylef/Spectre.git at 0.8.0 Cloning https://github.com/swift-tweets/OAuthSwift.git Resolving https://github.com/swift-tweets/OAuthSwift.git at 2.0.0-beta Cloning https://github.com/kylef/Commander.git Resolving https://github.com/kylef/Commander.git at 0.8.0 swift package edit TweetupKit 3.07s user 2.89s system 53% cpu 11.056 total $ (cd Packages/TweetupKit;git checkout master) Previous HEAD position was 71f0117... Merge pull request #11 from swift-tweets/dev-0.2.1 Switched to branch 'master' Your branch is up to date with 'origin/master'. $ swift build Updating https://github.com/koher/PromiseK.git Updating https://github.com/swift-tweets/OAuthSwift.git Updating https://github.com/kylef/Commander.git Updating https://github.com/kylef/Spectre.git Updating https://github.com/swift-tweets/tweetup-kit.git Fetching https://github.com/OAuthSwift/OAuthSwift.git Cloning https://github.com/OAuthSwift/OAuthSwift.git Resolving https://github.com/OAuthSwift/OAuthSwift.git at master Compile Swift Module 'PromiseK' (2 sources) Compile Swift Module 'Commander' (9 sources) Compile Swift Module 'OAuthSwift' (24 sources) …

(edited)

↑の状態で swift package reset してから swift build するとエラーになりませんか？

swift package resetするとeditモードから外れるので、その後にswift buildしてエラーになるのは当然かな。

そうか、swift package edit TweetupKit --revision 0.2.2すれば(cd Packages/…; git checkout …)とかしなくて良いのか。

https://github.com/apple/swift-package-manager/blob/master/Documentation/Usage.md

Can't use the library with Xcode · Issue #691 · stephencelis/SQLite.swift

swift-package-manager - The Package Manager for the Swift Programming Language

12:42 AM

swiftpmがpkgconfigでライブラリをリンクできるようになってたから

12:42 AM

システムインストールされてるCライブラリについては綺麗に組み込めるようになった

12:43 AM

しかし、プロジェクトごとにローカルビルドしてるCライブラリについては

12:43 AM

-Xlinkerでサーチパスを渡す必要があるので

12:44 AM

一貫してパスを渡せるように、swift build等をMakefileなどでラップする必要がある

12:45 AM

We plan to provide solution to avoid passing the flag in commandline.

12:46 AM

早く対応進んでほしいこれがないとなかなかC資産をフルに使ったSwift開発ができない

欲しい人が実装するしかない

できなくもないが他にやりたいことが多すぎる・・・

12:48 AM

コミュニティ的にはspmはあまり活発じゃないのかな？

12:48 AM

PRは監視してるけどあんまりモリモリ進んでないように思う

12:49 AM

Cファイルが入ってたらCターゲットってのと同じように、 Libsディレクトリにスタティックライブラリが入ってたら、それをリンクするだけのターゲットって仕様がいいかなーと思う

12:50 AM

ただOSや環境ごとに分けておかないといけないからそこらへんのフォルダ分けルールとかが悩ましい

どこまでevolutionを通して決めないといけないのか？があまりはっきりしていない様に見えるのが、個人的には手を出しづらいところ。>SwiftPM (edited)

たしかに・・・一応機能的なものはSE通しながら進んでるようには見えます

SwiftPMでObjectiveCのモジュールがあるとき、 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 (edited)

Hello, I have compilation problem with Xcode. Compilation was successful with swift build -Xlinker -lsqlite3 but i can't reproduce the same in Xcode. The module SqlLiteOBJ gives 22 errors. Do you h...

@import じゃなくて #import に書き換えてモジュール=NOのままやってみたら、今度は libsqlite3の自動探索がされなくなって(モジュールじゃないから) modulemapのlinkパラメータがxcodeprojに反映されないから駄目だった・・・

そのあたり改善するはずのPRが、最初の申請から1年近くに… https://github.com/apple/swift-package-manager/pull/1406

[Xcodeproj] Avoid generating module.modulemap if umbrella header exists, on creating Clang Module targets by norio-nomura · Pull Request #1406 · apple/swift-package-manager

This was rewritten #955 for master. This PR increases the portability of generated Xcode project by reducing the use of module.modulemap which absolute path contains. If clang module has umbrella...

ウオオまさにコレっぽそう

辛い・・・

ddunbar commented 26 days ago Sorry for the very long delay, I am testing and experimenting with this today...

SwiftPMでCのAPIを使う時に、apinotesを使えるらしい。 https://bugs.swift.org/browse/SR-6969

Package.swiftとは別のSwiftWorkspace.jsonを導入しようというモノらしい。 https://forums.swift.org/t/package-manager-workspace/10667

Package Manager Workspace

Hi, I would love to get some feedback on a draft proposal for introducing a feature called “workspace”. https://github.com/aciidb0mb3r/swift-evolution/blob/workspace/proposals/NNNN-package-manager-workspaces.md Package Manager Workspace Proposal: SE-NNNN Author: Ankit Aggarwal Review Manager: TBD Status: Discussion Introduction This proposal introduces a new concept called “workspace” to help Swift package authors to develop packages that depend on each other. Motivation Swift packa...

モチベーションはめっちゃわかる

1:01 AM

設定ファイルはswiftじゃなくてjsonなの？ってツッコミに対する回答がかなしいね

But I think that’ll be slow and painful in practice

https://forums.swift.org/t/package-manager-extensible-build-tools/10900 まだ読んでないけど。

Package Manager Extensible Build Tools

Hi, This draft proposal introduces extensible build tools in the package manager. It will allow package authors to integrate community build tools in the build process! https://github.com/aciidb0mb3r/swift-evolution/blob/extensible-tool/propos...

4:09 AM

Swiftで書いた独自ツールでビルドをフック出来るようにする提案かな？

かなり大掛かりな感じ。

今はllbuildにswift-compilerプラグインを組み込んだ外部実行ファイルswift-build-toolでビルドしているのを、llbuildのSwiftバインディングを使ってSwiftPM内から直接呼び出す様に変えることでswift-compiler以外のプラグインを使える様にし、PackageExtension.swiftでカスタムプラグインとそれを利用したルールを定義できる様な仕組みになるぽい？ (edited)

swift test --generate-linuxmainなんて出来るようになってたのね。

その機能なくて、自分で作ってました...。やっとできるようになったんですね

swift PM を使って build したものを、ここにあるようなやり方で REPL で読み込めたら良いなと思うのですが、僕なりに試した限りだとできなそうでした。 (edited)

7:25 AM

swift -I .build/debug/ -L .build/debug/ こういう風にすれば、import するとこまではできたのですが、実際に使おうとすると中身がないというようなことを言われてしまいます。 (edited)

7:26 AM

恐らくこれは上の記事にあるように lib がないからだと思うのですが。

7:31 AM

もし分かる方いたら教えてください

Package.swift の products が .library( type: .dynamic ) であることを確認して、

import PackageDescription let package = Package( name: "MyPMLib", products: [ .library( name: "MyPMLib", type: .dynamic, // < HERE targets: ["MyPMLib"]), ], ...

(edited)

11:32 AM

これで実行できました。 -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

おぉ…！！！！！

11:33 AM

ありがとうございます、後でやってみます！！！

ぬぉお、できました！

Package.swiftで、「MacかLinuxか」以外の、#if や普通の if での分岐をしている例ってありませんか？

https://github.com/ReactiveX/RxSwift/blob/master/Package.swift#L13

ReactiveX/RxSwift

RxSwift - Reactive Programming in Swift

おお。でもこれは・・・実質的に分岐してないですね

ですねぇｗ

10:43 AM

https://github.com/norio-nomura/GTMNSString_HTML/blob/master/Package.swift#L6

norio-nomura/GTMNSString_HTML

GTMNSString_HTML - Packaging GTMNSString+HTML.h as Swift Package

おー、言語バージョンなるほど。excludeは知らなかった。

https://github.com/search?utf8=✓&q=if+PackageDescription+extension%3Aswift+path%3A%2F+NOT+%22os%28%22+&type=Code あとは、環境変数系が多いですね。

そうやって検索したらよいのか。ありがとうございま

10:49 AM

す

if filename:Package.swift path:/ NOT "os(" のほうが正確っぽい。

参考になりました

アセンブラのソース.Sを含むライブラリをSwiftPMでビルドしたかったのだけど、.Sはサポートされてなかった。

2:00 AM

.Sを.cppの中に埋め込むとか出来ないかな…

Swift 4.2のswift package generate-xcodeprojには、Debug Build ConfigurationのSWIFT_ACTIVE_COMPILATION_CONDITIONSにSWIFT_PACKAGEを設定しないバグがある。 https://bugs.swift.org/browse/SR-7965

swift package generate-xcodeprojがC言語系のターゲットを生成する際module.modulemapにフルパスでヘッダが記載されるため生成されたXcodeプロジェクトがポータブルにならない、を改善するパッチがマージされました。 https://github.com/apple/swift-package-manager/pull/1602

[Xcodeproj] Use Xcode's modulemap generation when umbrella header ...

…present This makes the C language frameworks actual frameworks when umbrealla header is present in the target. It should be possible to embed these targets in other Xcode projects using subproject...

ターゲットと同名のアンブレラヘッダが存在する場合、SwiftPMはmodule.modulemapを生成せず、Xcodeが自動生成する仕組みを利用する様になります。

4

最近swiftpmのプルリクがたくさん処理されてるけど

2:33 AM

アップルの担当者が増えたりしたんですか？

Swift 4.0 -> 4.1くらいの間で swift package generate-xcodeproj で生成されるInfo.plistのBundle identifierがcom.yyy.Xxxxみたいなのじゃなくて、パッケージ名Xxxxだけになるようになってしまったような感じしてるのですが、どこで変わったか分かる人いないですかね

一気にprが増えたのはtry! Swift San Joseの効果ですかねー

ああー！

swift, foundation, swiftpm, swiftnioの4つが対象という感じだったので

パッケージ名Xxxxだけになるようになってしまった

swift-4.0-RELEASEで既にそうなってますね。

swift-4.0-RELEASEでなってるんですね…Xcode 9.2の時はリバースドメインになってた気がしてるんですが、勘違いかな Bundle Identifierがパッケージ名になるのって、意図した挙動なんですかね？iOSのイメージだとリバースドメインの形式な気がしてる

あ、正確にはパッケージ名ではなくターゲット名。 swift-3.0-RELEASEでもターゲット名になってました。

1:26 PM

SwiftPMにリバースドメインを教える仕組みが無いから仕方ないと思えます。

あーターゲット名ですね

12:44 AM

ドメインの方式にならないと、将来iOSで使えるようにする時に、code signing周りで不都合になるのではないかなと思ってたりしてます

その通りではあるのですが、自動生成はあくまで最低限Xcodeでビルド出来る様にするだけで、iOS等で利用する場合はそれら生成したプロジェクトを調整してリポジトリへコミットするのが前提になっているのだと理解しています。

iOS向けにはInfo.plistとかも必要だから、そうしたファイルを指定する機能が実装されて解決するんじゃないでしょうか

なるほど、背景にDIKitでこういう問題 https://github.com/ishkawa/DIKit/issues/53 があって、現状generate-xcodeしたあとに書き換えるしか方法がなさそうで、どうにか方法ないのかと調べているのでしたまだiOSにどうにかするにはいろいろと不都合が多いんですよね...

Can not install applications on the actual iOS machine · Issue #5...

Environment DIKit 0.3.2 Xcode 9.3.1 Swift 4.1 Current behavior There is no problem with the simulator, but applications depend on DIKit can not be installed on the actual iOS machine. -[MIExe...

ですね。spmのiOS対応には、この、プラグイン機能の実現の後で進むと予想してます https://forums.swift.org/t/package-manager-extensible-build-tools/10900

Package Manager Extensible Build Tools

Hi, This draft proposal introduces extensible build tools in the package manager. It will allow package authors to integrate community build tools in the build process! https://github.com/aciidb0mb3r/swift-evolution/blob/extensible-tool/proposals/NNNN-package-manager-exten...

1:27 AM

でも、スケジュールがハッキリしてないので、iOSに関しては今の所はspmは使わないのが無難と思ってます

DIKitに限っていえば、generate-xcodeprojを使わなければいけない理由がCYamlのmodule.modulemap内のパスが問題であるなら、CYamlターゲットをDIKit自身で持つ様にすれば解決可能です。 (edited)

1:28 AM

似た様なことをYamsでやってるので。 https://github.com/jpsim/Yams

jpsim/Yams

Yams - A Sweet and Swifty YAML parser.

（Yams 便利に使ってます。ありがとうございます

）

1

うおおお、見てみます！ @norio_nomura @omochimetaru ありがとうございます！

https://github.com/apple/swift-package-manager/pull/1604#discussion_r196286266

[Xcodeproj] Add support for automatic project generation by aciidb...

This adds a --watch option to generate-xcodeproj subcommand. SwiftPM will do the necessary configuration and exec to the watchman-make tool. If the tool can't be found on the system, it'll ...

11:18 AM

自動でxcodeproj再生成だって

DIKitでgenerate-xcodeprojした際CYamlターゲットのmodule.modulemapにフルパスが含まれる問題、Swift 4.2のスナップショットでswift package generate-xcodeprojするだけで解決する様になりました。 (edited)

1:32 AM

SwiftPMは作成済みのGeneratedModuleMap/CYaml/module.modulemapを削除してくれませんが、生成されたXcodeプロジェクトはmodule.modulemapを使わなくなるので、リポジトリから削除可能になります。 (edited)

おお

あ、ダメだ。

2:13 AM

生成されたXcodeプロジェクト自体に依存するパッケージをチェックアウトしたフルパスが含まれるから、意味がなかった… (edited)

2:14 AM

真の解決は、Carthageでサブモジュール管理してXcodeプロジェクトを手動で管理するしかないや。

2:15 AM

cocoapodsでもいけるのかな。

Carthage submodule + manual Xcodeproj 最強説

DIKitの場合、SourceKittenはXcodeプロジェクトが含まれてるけど、Stencilには含まれていないのがネックかな。 https://github.com/ishkawa/DIKit/blob/master/Package.swift

ishkawa/DIKit

DIKit - A statically typed dependency injector for Swift.

なるほどなるほど

swift-DEVELOPMENT-SNAPSHOT-2018-07-11-aでPackageDescription API v3が削除されたため、いくつかのパッケージがビルド出来なくなった… https://github.com/apple/swift-package-manager/commit/d9ae3a84d4860cd601ff2f336859a46f11cccc0c

Remove PackageDescription API v3 · apple/swift-package-manager@d9...

Remove PackageDescription API v3 from Swift 5

https://github.com/apple/swift-package-manager/pull/1704

[Build] Emit BuildPlan diagnostics to DiagnosticsEngine by aciidb0...

rdar://problem/41342798 SwiftPM is not warning about non whitelisted flags rdar://problem/40260898 [SR-7690]: SwiftPM does not print any warnings which is must be emitted at all during build plan i...

1:15 AM

5月に報告してたやつ、アンキットさんによって治った

SwiftPMでもswift test 2>&1 | xcprettyとすればxcpretty使えるらしい。 https://forums.swift.org/t/swift-test-output-format/14702/13

Swift test output format

This case with xcpretty is actually because swiftpm outputs test output to stderr, not stdout. So you need to run swift test 2>&1 | xcpretty

Carthageの binary サポートの挙動が微妙だ・・・

9:05 AM

carthage update した時点では /Users/omochi/Library/Caches/org.carthage.CarthageKit に zip ファイルがダウンロードされるだけで

9:05 AM

carthage build してはじめて、 Carthage/Build/iOS に zip の中身が展開される

9:06 AM

そして carthage update --no-build だと zipの展開が行われない (edited)

https://github.com/Carthage/Carthage/issues/2553

Expand binary package at checkout stage · Issue #2553 · Carthage...

Carthage downloads and expand contents in zip file at build stage not checkout stage. Its weird. I want to add process that expanding contents in zip at Carthage/Checkouts when user run $ carthage ...

duplicate issue立ってた。

Package.swift が swift-tools-version:4.0 の状態で swift build すると #if swift(>=4.2) が正しく動かないみたい。これはバグ？

6:15 AM

#if !swift(>=4.2) print("<4.2") #endif print(CountableRange<Int>.self)

6:15 AM

というコードに対して、

$ swift --version Apple Swift version 4.2 (swiftlang-1000.0.36 clang-1000.10.44) Target: x86_64-apple-darwin17.7.0 $ swift run <4.2 Range<Int>

6:15 AM

となる。

6:16 AM

CountableRange<Int>.self は Range<Int> になってるから中身は Swift 4.2 らしく、正しく分岐できずに困ったことになりそう。 (edited)

6:19 AM

Swift 4.1 だとちゃんと CountableRange になってる。

$ swift --version Apple Swift version 4.1.2 (swiftlang-902.0.54 clang-902.0.39.2) Target: x86_64-apple-darwin17.7.0 $ swift run <4.2 CountableRange<Int>

(edited)

#if swift(>=4.1.50)を使いましょう。 @swift-4.2.4 -swift-version 4 #if swift(>=4.1.50) print("4.1.50") #endif (edited)

4.1.50 (edited)

おお、過去に話されてましたね・・・

norio_nomura06/06/2018 > 話かわりますけど、Xcode 10 BetaはSwift4.1.50になるｗ Swift 4.2コンパイラに-swift-version 4を渡すと4.1.50になります。

6:22 AM

SwiftPM の swift-tools-version:4.0 の問題じゃなくて、コンパイラの -swift-version 4 時の挙動なんですね。

6:23 AM

互換モードでは CountableRange は typealias なんですね。そうじゃないと 4.2 と混ぜれないから当たり前か。なるほどー。

6:23 AM

ありがとうございました。

1

swiftpm でデバッグビルドのときだけ実行したい .testTarget を作ることはできるのでしょうか？ @testable import がリリースビルドだと出来ないので、public なAPIをテストするテストターゲットと、internal なユニットテストを分けて、 swift test -c release のときには後者は実行しないようにしたいのです。 (edited)

Package.swiftの中で #if DEBUG は使えるのかな

だめっぽいです

https://github.com/apple/swift-package-manager/blob/master/Sources/PackageLoading/ManifestLoader.swift も見たけどconfigurationは何もしてなさそうですね……

ReactiveCocoa/ReactiveSwift

The Package Manager for the Swift Programming Language - apple/swift-package-manager

たしかに普通にありそうな要望っぽいけどどうしたらいいんでしょうね

5:46 AM

個人的に @testable 使わないから気づかなかった

環境変数は使えたと思うので import Foundation して ProcessInfo.processInfo.environment でどうにかするとか

5:49 AM

以前こういうことをしていた https://github.com/ReactiveCocoa/ReactiveSwift/blob/62cbc3119533bcb420e0e717472b7e88d70e3f09/Package.swift#L4-L8

Streams of values over time. Contribute to ReactiveCocoa/ReactiveSwift development by creating an account on GitHub.

リリースビルドでも-enable-testingを指定したら@testable importできません？

5:51 AM

なんか前にやった記憶があるんですよね。

(今手元で実験中)

それかgenerate-xcodeprojしてxcodebuildでテストするとか。

確かにReleaseでも@testable有効にしてテストするのはありかも。Xcodeでのテストで同じようなことはしています https://github.com/ReactiveCocoa/ReactiveSwift/blob/2463d83d0c896ac046c2b85377e583b72373b831/script/build#L35

ReactiveCocoa/ReactiveSwift

Streams of values over time. Contribute to ReactiveCocoa/ReactiveSwift development by creating an account on GitHub.

-Xswiftc -enable-testing で @testable import はできるのですが、リリースビルドの成果物はそのままリリースに回したいので、、、というところで。

なるほどー

/Users/omochi/temp/spmdb/Tests/zooTests/spmdbTests.swift:2:18: error: module 'zoo' was not compiled for testing @testable import zoo ^

5:56 AM

たしかに -c release のときだけここでこけますね、そのままやると。

というか、最終成果物で、テストのサブセット(public APIテストのみ) をクリーンに回す方法が現状ないということ？

ターゲットは分けないで、testable importするファイルは分けてそのファイル内で #if DEBUG で囲んでしまえば、きれいではないけどいける気はする

public API のテストだけなら普通の import でできそうです

おお、テストファイル内での #if DEBUG は出来るのですね。

5:59 AM

それでいけそうです！

Linux向けの allTests の定義で Releaseで消えるやつは除去する必要がありそうですね

たぶんターゲット内の各ファイルのビルド時は渡してくれる気がします（が確信はない）

なんとなくわかってきました。 #If DEBUG @testable import zoo #else import zoo #endif ^ これと、それぞれInternalにアクセスするテストを囲う感じですね。

Linux向けの allTests の定義で Releaseで消えるやつは除去する必要がありそうですね

めんどうそうｗ

6:04 AM

皆様ありがとうございます。 @testable import するテストはファイルを分けて、ファイル全体を #if DEBUG で囲う方向でやってみます。 (-D DEBUG が渡っていることは確認しました) (edited)

1

#if canTestableImport(…) とかあれば良いのに。

swift package generate-xcodeproj の出力が、実行毎に変わるようになったのって、Swift 4.2からで合ってますかね？

8:38 AM

SwiftPMだとxcodeprojはignoreされる前提でgenerateされるとは知りつつ、別のツールに移行するしかないのかなの判断がつかない状態なので、わかる方いましたら https://github.com/ishkawa/DIKit/issues/58

The xcodeproj is changed every time generate with Xcode 10. · Iss...

I'm trying to support Xcode 10. However, the generated xcodeproj is changed every time when I execute swift package generate-xcodeproj . Swift Package Manager is not yet suitable for iOS. I thi...

xcodeprojを手動でメンテナンスしたくない理由って何なのだろう？

swift build でビルドできる必要があるので

9:44 AM

手動メンテした結果、xcodeprojではビルドできるが、swift buildではできない、みたいなことが起こったら嫌だし、

9:45 AM

SwiftPMがビルドに必要な知識は全て持ってるので、それをxcodeprojに書き写すのは機械にやらせたほうが間違いがないから (edited)

9:45 AM

と僕は思ってます

今のSwiftPMの仕組みだと、外部依存するパッケージが存在する時点で、生成したxcodeprojをリポジトリに入れても使えないよね。

外部依存というのが、例えばDIKitのような、独自のメタビルド機構の事なら、そうですね。

9:53 AM

メタプログラミングとかだったら、生成されたソースコードをコミットすれば良い場合もあるけど

9:53 AM

事前にコミットできないタイプのものは、SwiftPMでは対応できないですね。

9:55 AM

そのあたりは、SwiftPMのPackageExtensionが将来的に担うところ。 https://github.com/aciidb0mb3r/swift-evolution/blob/extensible-tool/proposals/NNNN-package-manager-extensible-tools.md

aciidb0mb3r/swift-evolution

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - aciidb0mb3r/swift-evolution

外部依存するパッケージはPackage.swift内のdependenciesの事。生成されたxcodeprojには.build/checkouts下のパスが含まれるから、Xcodeでビルドする前にSwiftPMでもビルドしないといけないから、都度generate-xcodeprojするのと変わらない。

ああ、そういうことか。

10:06 AM

実行毎に変わるようになった

ってそういう話なのかな？

10:07 AM

チェックアウトされたところのパスですけど、なんか、ハッシュ値みたいな謎の数列が付与されたディレクトリにチェックアウトされていたけど、

10:07 AM

その数列に再現性があった気がする。

10:07 AM

本来はそこのレイアウトはSwiftPMのチェックアウト実行ごとに定まるから、xcodeprojは共有できなかったけど、

10:07 AM

実際は昔はそこが共有することもできていた？

そこに再現性があっても、リポジトリに入ってない.build/checkoutsを用意する為にはSwiftPMを使わないといけない。それならgit submoduleで管理した方が良いのでは、と思えてしまう。

たしかにそうですね。

xcodeprojの生成時にHashable.hashValueに依存する何かがあって、ランダムハッシュシードによって毎回変化があるようになったとかかな

たしかに4.2でhashの挙動変わったからそれが原因なのかも

一応環境変数でランダムシードは無効化できるので、それでコマンド実行試すと分かるかも。

10:43 AM

SWIFT_DETERMINISTIC_HASHING=1

2

リポジトリにxcodeproj入れるのをやめた方が良い気が…

リポジトリに入れないとCarthage対応できない

それはまたちょっと話が違ってくると思う

それでReactorKitとかはCarthage対応が切り捨てられてます

10:45 AM

いや今回のDIKitのケースはそういう話ですね (edited)

Carthageって.xcworkspaceでもいける？

Carthage対応のために用意するxcodeprojはCarthageのルールで設置されるディレクトリに依存物が入っているから

10:45 AM

SwiftPMでcheckoutする依存物のフォルダ名の謎の数列とはまた別では

workspaceでOKです

10:46 AM

それとは別の話ですが、ランダムハッシュシードが

SwiftPMのgenerate-xcodeprojで作られるxcodeprojと、CarthageでiOSとかで使えるようにするために設置するxcodeprojは、互換性が取れない

xcworkspaceで行けるなら、SourceKittenみたいに手動でメンテナンスするのが良いと思う。

うーん話が混線してしまった

DIKitの場合、今リポジトリに入ってるxcodeprojではCarthageでビルド出来ないのでは。

今までできてたのです

その際、.build/checkoutsはどの様に用意してたのですか？

ん、DIKit.framework自体（ランタイム用）には依存性はありません

ああ、DIKitを使うDIGenKitが使うのですね。

10:52 AM

あれ？それで.build/checkoutsが無くてもCarthageでビルド出来ていたって事ならば、.build/checkouts以下のパスに再現性が無くても構わないという事になりそうな気が…

はい、なのでそこが混線しているところで、checkoutsのパスの数列の件と、generate-xcodeprojの生成結果に毎回差分があるのは別の話だと思うのです。 (edited)

2

なるほど。

ランダムハッシュシードがそれぞれに別々に関係しているのでは、と思っていたのが先の発言です (edited)

10:58 AM

SwiftPMのgenerate-xcodeprojで作られるxcodeprojと、CarthageでiOSとかで使えるようにするために設置するxcodeprojは、互換性が取れない

取れないケースもあるけど、ちょっとだけ手を入れると取れるケースもあるんですよね（それがDIKitのケース）

DIKit自身に依存先が無いなら、いけそうですね。

何をしてるかはDIKitのMakefileを見てもらうとよさそう

11:01 AM

Carthage/Checkoutsなどを突っ込むのと同じで.build/checkoutsもリポジトリに突っ込んでしまえば依存性あるケースでもいけるのかもしれない

11:02 AM

で、話を戻すと、generate-xcodeprojの生成結果が決定的にできるなら今のやり方でもいいし、そうでなければXcodeGenみたいな別ツール使うか、みたいな話なのでした

11:03 AM

もしくは普通に手でxcodeproj作って管理するか

試してみましたが、.build/checkouts内のパスも変わるし、project.pbxproj内の要素の順番とかも変わりますね。

11:09 AM

生成されたxcodeprojからDIKit.framework以外の要素を手動で削除してしまえば良いのかも。

1

https://github.com/apple/swift-package-manager/blob/235aacc514cb81a6881364b0fedcb3dd083228f3/Sources/PackageGraph/PackageGraph.swift#L23-L33 この辺で Set 使っていてこの PackageGraph から諸々生成しているので、ランダムシードの影響受けるのは必至なのですが、手元で試した限り env SWIFT_DETERMINISTIC_HASHING=1 swift package generate-xcodeproj でも阻止できないので、やっかいですね。

The Package Manager for the Swift Programming Language - apple/swift-package-manager

2

1

ちなみにcheckoutsのパスはこれのはず

The Package Manager for the Swift Programming Language - apple/swift-package-manager

The Package Manager for the Swift Programming Language - apple/swift-package-manager

手元で SWIFT_DETERMINISTIC_HASHING 試したら name = "Products"; の箇所だけなぜか順番が変わるけど、そこ以外は安定してる

 "OBJ_162" = { isa = "PBXGroup"; children = ( "Yams::Yams::Product", "DIKit::dikitgen::Product", "Yams::CYaml::Product", "PathKit::PathKit::Product", "DIKit::DIGenKit::Product", "Stencil::Stencil::Product", "DIKit::DIGenKitTests::Product", "Spectre::Spectre::Product", "DIKit::DIKit::Product", "SWXMLHash::SWXMLHash::Product", "SourceKitten::SourceKittenFramework::Product" ); name = "Products"; path = ""; sourceTree = "BUILT_PRODUCTS_DIR"; };

12:31 PM

こんなコメントがあった https://github.com/apple/swift-package-manager/blob/ddfe6e23f3eaf3f79e003d872b6072a2686b4c88/Sources/Xcodeproj/XcodeProjectModel.swift#L52-L54

 - 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

(edited)

The Package Manager for the Swift Programming Language - apple/swift-package-manager

たしかに env SWIFT_DETERMINISTIC_HASHING=1 swift package generate-xcodeproj で実行すると、hashは固定されるけど、根本的にだめな気がしてきた... (edited)

DIKitのdependenciesをsubmodule化したモノ作ってみた。 https://github.com/ishkawa/DIKit/compare/master...norio-nomura:update-xcodeproj

ishkawa/DIKit

A statically typed dependency injector for Swift. Contribute to ishkawa/DIKit development by creating an account on GitHub.

1

submodule管理はCarthageで。 (edited)

3:54 AM

generate-xcodeprojで生成したproject.pbxprojの.build/checkouts/*をCarthage/Checkouts/*へ書き換え。

3:55 AM

Swift 4.2で不要になったmodulemap削除。

3:56 AM

Package.swiftへの参照は、親グループの複数パターンに対応できない為にリンク切れになってるけど、ビルドに影響ないので放置。

3:57 AM

そんな感じ。

Carthageフロントエンド+git submoduleだ

CartfileではなくCartfile.privateを使うべきなのかも。

そういえば昨日の @rintaro さんのやつ、 Package.swift 側で↓のようなアプローチは使えないかと思ったけど、

// swift-tools-version:4.2 // The swift-tools-version declares the minimum version of Swift required to build this package. import PackageDescription var targets: [Target] = [ .target( name: "Foo", dependencies: []), .testTarget( name: "FooTests", dependencies: ["Foo"]), ] assert({ targets.append( .testTarget( name: "FooDebugTests", dependencies: ["Foo"]) ) return true }())

DEBUG が渡らないだけじゃなくて、 -c が Package.swift を debug/release のどちらで実行するかに影響を与えるわけではない（ -c release でも debug っぽい）みたいでダメだった。

そうですねー、Package.swift のロード（実行）のコマンドは https://github.com/apple/swift-package-manager/blob/106115d356f750223dbd4419c3f39f8fc2da66f7/Sources/PackageLoading/ManifestLoader.swift#L310-L329 この辺だと思っていて、そこでconfigurationを渡していないようなので。渡すようにしたPR出すのはありやなしや。

Add support for Swift REPL by aciidb0mb3r · Pull Request #1793 ·...

The Package Manager for the Swift Programming Language - apple/swift-package-manager

Package.swift の実行に configuration が反映されれば色々できそうですが、一方で -c は Package.swift についてではないよなぁという気もしますね。それよりも DEBUG 等が Package.swift にも渡される方が良さそう？

確かに最適化まではされる必要もないし、直接configurationが渡されるよりは、-c debugの時は-D DEBUGも指定、くらいが妥当そう

1

Package.swiftはSwiftコードだから分岐できるとかは全然いいと思うんですが、それをやり始めるとDSLとしてはけっこう大変になるので、私ならリジェクトしたいかも。

僕も動的な事は全部PackageDescription型のプロパティで表現できる範囲に済ませたい

5:46 AM

例えば、Target型に var disableWhenDebug: Bool があってスイッチできる、みたいな感じで。

Swift PM 使って書いてるスクリプトで↓のエラーで困ってるんですが、 10.12 以降でだけ使えればいいんで、これをビルド時に簡潔に指定する方法ってありませんか？ Xcode プロジェクト側ではなく、コマンドか Package.swift とかで。

error: 'iso8601' is only available on OS X 10.12 or newer public static let dateDecodingStrategy: JSONDecoder.DateDecodingStrategy = .iso8601

↓でいちおうビルドできるんですが、もっと Swift PM 的に良い方法はないかなと。 swift build -Xswiftc "-target" -Xswiftc "x86_64-apple-macosx10.12"

ソース内で if #available(OSX 10.12, iOS 10.0, watchOS 3.0, tvOS 10.0, *) { を使わずに？

はい。それを使うと↑の dateDecodingStrategy にアクセスした箇所全部で分岐が必要になってしまうので・・・。

9:41 AM

10.12 以降のみの利用を想定しているので、コード上であまりがんばりたくない感じです。

-Xswiftcでの指定しか僕も知らないですね……

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({ ^

1

swift-DEVELOPMENT-SNAPSHOT-2018-10-01-aでswift run --replが出来る様になりました。 https://github.com/apple/swift-package-manager/pull/1793

This adds a --repl option to swift run which will build the package and launch the Swift REPL. All reachable library modules will be accessible in the REPL. It works by generating a special dylib p...

4:25 AM

パッケージをビルドしてからインポートできる状態でSwift REPLが起動します。

便利そうですね

おお良さそう

https://github.com/apple/swift-package-manager/pull/1810

Prefix public stdlib extensions with spm_ by aciidb0mb3r · Pull R...

Extensions are very easily leaked into the clients. Since Swift doesn't have the concept of private imports at this point, it is not safe to have public stdlib extensions as it can easily cause...

2:38 AM

これ、 .spm.shellEscaped 式にできそうだね

Swift 4.2からswift test --parallel --xunit-output result.xmlとか出来る様になってたの知らなかった。 https://github.com/apple/swift-package-manager/commit/047df6464ab15e27ab19b9a8263caeaf32127065

[SwiftTestTool] Add support for generating xUnit xml file · apple...

This generates xUnit xml file when the option --xunit-output is specified with the parallel test runner. This is a very minimal implementation and is currently hidden from help. We should try to ge...

3:06 AM

--xunit-outputを使うには--parallelが必要。

3:13 AM

どうやら--xunit-outputは未完成の機能だから--helpには出てこないらしい。

result.xmlが出せる嬉しさがよくわからないんですが、XcodeからSwiftPM経由でテストを実行してその結果をXcodeにGUIで返す、みたいな事ができるようになる？

CircleCIやAzure Pipelinesとか、xUnitの出力をWebのUIに出せたりします。

3:24 AM

テスト結果表示をサポートしてるCIでxUnit対応はかなり多いはず。

3:26 AM

今はxcpretty -r junitとかで生成してるのが不要になる。

あ〜なるほど、それは嬉しいですねえ

質問なのですが、Swift PM って dylib とかを同梱する機能ってあるんでしょうか？

11:43 AM

新しい SwiftSyntax は lib_InternalSwiftSyntaxParser.dylib を要求するので、何らかの方法で同梱しないといけないはずなのですが、issue 検索しても native extension 的な話は出てこないんですよね。。。

バイナリを同梱する機能は無いと思います。

11:47 AM

パッケージのリポジトリに含めておいて、dlopenで動的にロードする事は頑張れば出来そうな気もしますが、試した事は無いです。

11:49 AM

あ、dlopenも無理かな。

やっぱりそうですよね、今って Package.swift から linker や swiftc へオプション渡す記法も存在しなさそうだし、SwiftSyntax チームはどうするつもりなんだろう…

Toolchainへ同梱するのでは。

あー、なるほど…

11:49 AM

その可能性は濃厚ですね。ありがとうございます。確かにおっしゃる通りです

11:50 AM

うーん、困ったな。。。

swift-DEVELOPMENT-SNAPSHOT-2019-03-04-aには含まれてるみたいですよ。

おお、なるほど！

11:56 AM

あー、そういうことか。つまり native extension 使いたければ include path に自分で dylib 入れとけって話になるわけですね。。。

11:57 AM

そして公式のやつはビルトインされると。

11:59 AM

その bridge は SwiftPM へ同梱する感じですね。https://github.com/apple/swift-syntax/tree/master/Sources/_CSwiftSyntax

apple/swift-syntax

SwiftPM package for SwiftSyntax library. Contribute to apple/swift-syntax development by creating an account on GitHub.

11:59 AM

理解しました。

SwiftPMからPOSIXモジュールを削除するPR https://github.com/apple/swift-package-manager/pull/2053

Eliminate POSIX by aciidb0mb3r · Pull Request #2053 · apple/swif...

The POSIX module in SwiftPM was written before corelibs-foundation was mature enough. This module provided a great value but isn't good in the long term since we want SwiftPM to be as cross-pla...

いいですねえ

https://github.com/apple/swift-package-manager/releases

The Package Manager for the Swift Programming Language - apple/swift-package-manager

2:47 PM

2:47 PM

Swift PM ってリリースされないんですっけ？

2:49 PM

master にも swift-5.0-branch にも PackageDescriptionV5.md がない？ https://github.com/apple/swift-package-manager/tree/swift-5.0-branch/Documentation

Swift PM, Bundles and Resources

The Package Manager for the Swift Programming Language - apple/swift-package-manager

2:51 PM

↓をチェックすればよい？ https://swift.org/blog/swift-5-released/#package-manager-updates

Swift 5 Released!

Swift 5 is now officially released!

内容は同じだけど、僕はこっちを見るかな。 https://apple.github.io/swift-evolution/#?version=5&search=Package

なるほど、ありがとうございます

SwiftPMのリソースサポートの進捗を調べた。話してるスレッド https://forums.swift.org/t/swift-pm-bundles-and-resources/13981 によると、OSS FoundationにBundleサポートを実装すれば、SwiftPMでそれを取り扱えるようになる、という流れで、 Bundleの仕様書がここ https://github.com/apple/swift-corelibs-foundation/blob/master/Docs/FHS%20Bundles.md#freestanding-bundles Bundleの実装が、2018年1月に出て https://github.com/apple/swift-corelibs-foundation/pull/1573 でも完了してなくて、 26日前に別PRのBundle実装が出てマージ待ち https://github.com/apple/swift-corelibs-foundation/pull/2093 SwiftPM側のリソースサポートの提案の下書きがコレ https://github.com/abertelrud/swift-evolution/blob/package-manager-resources/proposals/NNNN-package-manager-resources.md というわけで、ゆっくり進んでる事がわかった

Once Swift Foundation PR #1573 and #1570 are merged we will be able to use Bundle API on Linux with Freestanding bundles. This means that with the following structure: FooExecutable FooExecutable.resources/Info.plist FooExecutable.resources/FooResource.json libBarLibrary.so ...

apple/swift-corelibs-foundation

The Foundation Project, providing core utilities, internationalization, and OS independence - apple/swift-corelibs-foundation

[SR-953] Implement Bundle(for: class) by millenomi · Pull Request...

Implements Bundle(for:) by using dladdr() on the type descriptor of a class. For further discussion, see apple/swift#16964, which is a dependency of this patch. Resolves SR-953.

Complete Freestanding Bundles support in all platforms by pvieito ...

Adds support for finding the bundle path for implicitly loaded bundles (for which we only know the executable path). Unifies Windows and other platforms implementation. Enables Freestanding Bundles...

abertelrud/swift-evolution

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - abertelrud/swift-evolution

2

9:54 AM

PR1573はBundle(for: class)で、Bundle実装自体は1570だけどcloseされて2093に引き継がれたんだ。 https://github.com/apple/swift-corelibs-foundation/pull/1570 Bundle(for: class)のためにtypedescriptorを取るランタイム関数がSwiftランタイムに追加されて、その結果のシンボルをdladdrにかけてdylibの名前を参照してる。

Added support for Freestanding Bundles reverse lookup by pvieito ...

This enables finding Freestanding bundles directory from the executable path as specified on the FHS Bundles doc. Unifies Windows implementation with other platforms.

BundleとはいうもののUNIX流儀に合わせて/shareとか/libに中身をバラバラに展開する考えっぽい。面白い。

SwiftPMのC Target、特定のファイルの置き方をしていたかどうかによって、２種類の取扱があるっぽい。

3:52 AM

おそらく Sources/${target}/include/${target}.h が置いてあり、かつ、 modulemapが置いてないときに限って

3:52 AM

DEFINES_MODULES = YES になるモードになって

3:52 AM

どっちかの条件でも満たしていないと、 DEFINES_MODULES = NO になるっぽい。

https://github.com/apple/swift-package-manager/blob/master/Documentation/Usage.md#c-language-targets

[Xcodeproj] Avoid generating module.modulemap if umbrella header...

The Package Manager for the Swift Programming Language - apple/swift-package-manager

5:04 AM

この辺か。

swift package generate-xcodeproj の挙動ならば、僕が提案したモノですね。

おお、元はどういう挙動だったんですか？

12:27 PM

modulemapを置いた時点で構造の自由度がframeworkの構造を超えてxcodeから使えなくなるので、今の挙動自体はこれで正しいと思います

12:28 PM

本当はxcodeに依存ターゲットからheader search pathを継承するような機能が欲しいけど。。

以前は無条件にmodule.modulemapを生成して、それ経由でリンクしていたはずです。 https://github.com/apple/swift-package-manager/pull/1406

This was rewritten #955 for master. This PR increases the portability of generated Xcode project by reducing the use of module.modulemap which absolute path contains. If clang module has umbrella...

12:38 PM

あ、マージされたのはこっちか。 https://github.com/apple/swift-package-manager/pull/1602

[Xcodeproj] Use Xcode's modulemap generation when umbrella header ...

…present This makes the C language frameworks actual frameworks when umbrealla header is present in the target. It should be possible to embed these targets in other Xcode projects using subproject...

なるほど！

12:39 PM

SwiftPMが作るやつはフルパスになってしまって、生成物を共有できないから

12:40 PM

依存元がSwiftPM以外の場合に不便なことになるので

12:40 PM

いける場合はxcodeのdefine moduleになるのは助かる

https://github.blog/2019-06-03-github-package-registry-will-support-swift-packages/

Simina Pasat

GitHub Package Registry will support Swift packages

Today we’re excited to announce that we’ll be adding support for Swift packages to GitHub Package Registry. Swift packages make it easy to share your libraries and source code across your projects and with the Swift community.

12:26 AM

GitHub Package RegistryがSwift Packageをサポートすると聞いて、BetaにSign Upしておいた。 https://github.com/features/package-registry/

GitHub Package Registry: Your packages, at home with their code

With GitHub Package Registry you can safely publish and consume packages within your organization or with the entire world.

swiftのサンプルはまだ載ってないですね。 spmの場合はリポジトリURLをそのまま指定してましたがそのへんがどうなるんだろう……

SwiftPMってstatic linkだけでしたっけ？今までちょっとしたツールのmac向けコンソールアプリでしか使ったことなかったし、そのあたり全く気にしてませんでした。

https://github.com/apple/swift-package-manager/blob/master/Documentation/PackageDescription.md

https://forums.swift.org/t/swift-pm-bundles-and-resources/13981/24

The Package Manager for the Swift Programming Language - apple/swift-package-manager

3:50 AM

.library(name: "PaperDynamic", type: .dynamic, targets: ["Paper"]),

3:50 AM

指定はできるみたいです

あ、そうなんですね。

Leave this parameter unspecified to let to let the Swift Package Manager choose between static or dynamic linking (recommended).

オススメはSwiftPMに任せる、なんですね。

2

Swift PM, Bundles and Resources

There's already a proposal draft by @abertelrud which was also mentioned in this WWDC session. They specifically asked for community feedback on the proposal and implied that Apple would do any work needed to update the Xcode integration once SwiftPM implemented support for r...

4

7:30 AM

7月以降にリソースプロポーザル出そう by Ankit

Linux上にて $ swift test --generate-linuxmain warning: can't discover tests on Linux; please use this option on macOS instead #if os(macOS)でmac専用のテストを書いている場合、mac上でgenerate-linuxmainするとそれらも含まれてしまうので微妙……

なるほどw

5:30 AM

#ifをテストケースの内側に書くと良いのでは

5:30 AM

違うプラットフォームでは空のテストにする。

そうですね。それがいいかと思ってました。

5:31 AM

複数のテストをまとめてくくっている場合がちょっと面倒ですが

あとは、generatelinuxmainが次で不要になりそうだから、それまで待つか

test discoveryでしたっけ

うん

Package Descriptionのドキュメントページがあるの知らなかった。いつもgithub.comへ見に行ってた… https://docs.swift.org/package-manager/PackageDescription/PackageDescription.html

僕も！w そこにあったのか。

https://swift.org/package-manager/ でドキュメントを探すとGitHubへ誘導されるし。 (edited)

Ankit Aggarwal (@aciidb0mb3r)

Swift is a general-purpose programming language built using a modern approach to safety, performance, and software design patterns.

まだ出来たばかりだったらしい。 https://twitter.com/aciidb0mb3r/status/1151658511446597632

@norio_nomura @daniel_duan Yep, it’s new. I need to add its link in other pages.

https://github.com/apple/swift-package-manager/pull/2241

Rename modules. Add prefixes. by krzyzanowskim · Pull Request #2...

For: https://bugs.swift.org/browse/SR-11151 Basic -> SPMBasic SourceControl -> SPMSourceControl Build -> SPMBuild Workspace -> SPMWorkspace

1

7:11 AM

SwiftPMのターゲット名のパッケージ名にSPMってプレフィックスを付けるそうな。

7:11 AM

結局そうなるんかい・・・

ネームスペースとはなんだったのか…

SwiftPMをコマンドラインから使った場合は実行ファイルに

Load command 20 cmd LC_RPATH cmdsize 120 path /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx (offset 12)

3:25 AM

これが設定されるけど

3:26 AM

Xcode11からPackage.swiftを開いてビルドした場合は

Load command 20 cmd LC_RPATH cmdsize 32 path /usr/lib/swift (offset 12) Load command 21 cmd LC_RPATH cmdsize 40 path @executable_path/../lib (offset 12)

3:27 AM

こうなっていて、通るパスが違う。というか、xcode11のツールチェインを見るようになってねえ。

3:27 AM

それで、 #swift-syntax に書いたけど、SwiftSyntaxが使えない。

DYLD_LIBRARY_PATHをチェックして、rpathへ設定するパッチ。

@@ -0,0 +1,35 @@ diff --git a/Package.swift b/Package.swift index 8234442cbb68248f8c541e8af979c538c72df0a6..abf133e63098c7bf46cb28bb971e21afae5e462b 100644 --- a/Package.swift +++ b/Package.swift @@ -1,4 +1,4 @@ -// swift-tools-version:4.2 +// swift-tools-version:5.0 //===----------------------------------------------------------------------===// // // This source file is part of the Swift.org open source project @@ -12,6 +12,7 @@ //===----------------------------------------------------------------------===// import PackageDescription +import Foundation let package = Package( name: "swift-format", @@ -64,7 +65,15 @@ let package = Package( "SwiftFormatConfiguration", "SwiftFormatCore", "SwiftSyntax", - ] + ], + linkerSettings: { () -> [LinkerSetting] in + if let DYLD_LIBRARY_PATH = ProcessInfo.processInfo.environment["DYLD_LIBRARY_PATH"]? + .components(separatedBy: ":") { + let flags = DYLD_LIBRARY_PATH.flatMap { ["-rpath", $0] } + return [.unsafeFlags(flags)] + } + return [] + }() ), .testTarget( name: "SwiftFormatRulesTests",

Package Manager関連が余分なので、フィルタとかすべき。

おお、linkerSettingsでrpathを注入できるのか！

4:22 AM

実行時のことだけ考えてたけど、バイナリ生成時にそのへんに手を入れればいいのか、ありがとうございます。

SwiftPM の dependencies で from: ではなく .branch("...") でレポジトリを指定してあるとして、branch のコミットが進んだときに「そのブランチの最新コミットを fetch し直す」ってできるんでしょうか？（ .build と Package.resolved を消して swift build し直せばできるのですが…） (edited)

swift package updateかな？

おぉ、そんな便利なものが！

xcodeproj でやってるビルドは全て swift build に適切なオプションをつければ実行できるものなのでしょうか？（例えば Bridging-Header の指定とか、C++ の Standard Library の指定とか）この辺のことの仕様ってどこかにまとまっていたりしますか？ (edited)

全ては無理だと思います bridging headerはspmに無いと思いますドキュメントは https://swift.org/package-manager/ https://github.com/apple/swift-package-manager/blob/master/Documentation/Usage.md ぐらい詳細はソース見る必要がありそう

Swift is a general-purpose programming language built using a modern approach to safety, performance, and software design patterns.

[WIP] Implement test discovery on linux by aciidb0mb3r · Pull Req...

The Package Manager for the Swift Programming Language - apple/swift-package-manager

なるほど！bridging-header がないってことは、Obj-C や C++ を含むコードは swift build できないってことですかね？ (edited)

4:25 PM

Xcode がどういうコマンドでビルドしてるかってのを見ることはできるんでしょうか？

swiftpmはC系のビルドにも対応してますが、 Swiftとはターゲットを分ける必要があります xcodeのコマンドはビルドログのところで全部見れます

4:28 PM

ブリッジングヘッダーは一つのターゲットの中でCとSwiftを混ぜる仕組みなので。

なるほど…

（原理的にはできるけど設定が大変という理解であってますか？） (edited)

むむぅ、そもそも project の中に swift 以外のファイルが入ってると generate-xcodeproj もできないんですね…

5:33 PM

SwiftPM で管理してる純 Swift のライブラリを、Obj-C や C++ 入りのプロジェクトから SwiftPM 経由で fetch してくるってのはできないんですかね…

純 Swift 部分と、Obj-C / C++ 部分で target を分けて、前者から後者をライブラリ経由で呼び出せばいけるんですかね？ (edited)

やりたいのはこういうことです：・A : Swift 製ライブラリ (Swift PM 管理、自作) ・B : C++ 製ライブラリ (3rd Party 製) ・C : A, B を使う Swift 製プログラム（B の利用は Obj-C++ wrapper を経由）・C を Swift PM 管理にしたい、特に A の変更を簡単にアップデートできるようにしたい (edited)

CもライブラリでCを使うアプリケーションが別途あるんですか

6:21 PM

いやCはExcutableか。

要するにObjC++のライブラリとリンクするパッケージが作れたらいいんですよね。

. ├── 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

7:13 PM

これを基本形としてあとはこれの応用だと思います。

ちょうどぼくも先週、同じようなことを模索してました。

1:23 AM

ObjCとSwift混在のアプリ（App）のうち、一部のSwiftをSwiftPMのパッケージ（Foo）に切り出そうとしてたんですが、切り出すとAppのObjCからFooを呼び出せなくなって。呼び出せないというか、Fooに切り出した分がApp-Swift.hに出てこなくなるからヘッダがなくなってしまって。

1:28 AM

今のところ、Foo側で、手動で swiftc を -emit-objc-header 付きで呼び出してFooの分のヘッダを作成して、そのヘッダを参照できるだけのCモジュールもFoo側に作って、AppではそのCモジュールを参照するようにしたんですが。

1:33 AM

パッケージの構成はこんな感じで

├── Package.swift └── Sources ├── Foo │ ├── Foo1.swift │ ├── Foo2.swift │ └── FooN.swift └── CFoo ├── Foo.m └── include └── Foo-swift.h

1:34 AM

Package.swiftがこんな感じです。

// 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"), .target(name: "CFoo", dependencies: ["Foo"]) ] )

(edited)

1:36 AM

Foo.mの中身は空っぽで、Foo-Swift.hが -emit-objc-header で作ったヘッダファイル。 App側でCFooを参照すれば、ObjCでも、 @import CFoo; だけでヘッダの参照ができるようになりました。 (edited)

1:40 AM

ただ、Foo側のコードを変更した時に Foo-Swift.h を更新するのがすごく面倒で…

むむ…僕の問題は @Kishikawa Katsumi さんの書いてるやり方でできれば良いと思うのですが、 @hironytic さんはそれではできないということを書かれてるのでしょうか？ (edited)

2:04 AM

ObjC → Swift の呼び出しできない、というところが問題？（僕の問題と逆のケースですかね？） (edited)

そうですね。ぼくのは ObjC → Swift の呼び出しができずに困ってました。それで、とりあえず呼び出しはできるようになったんですが、FooのSwiftファイルを変更したときにObjC向けヘッダーを手動で更新しないといけないところが運用上の課題、という現状です。

ふむふむ、理解しました。

たぶん岸川さんのやりかたでうまくいくんじゃないかと思ってます。

1

FooのSwiftファイルを変更したときにObjC向けヘッダーを手動で更新しないといけな

// 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"]) ] )

とか。 (edited)

2

@norio_nomura それcool！！

@norio_nomura おー！明日やってみます

10:58 AM

あ、でも、unsafeFlagsを使ってるパッケージって、他から利用しようとしたらエラーになった覚えが。

あー、確かにそう書かれてた。

/// As some build flags could be exploited for unsupported or malicious /// behavior, the use of unsafe flags make the products containing this /// target ineligible to be used by other packages.

知りませんでした…

1

@Kishikawa Katsumi さんのやり方で generate-xcodeproj して（ビルド設定を追加した上で）実行できました！そこで以下のビルド設定も Package.swift の中に入れられると嬉しいのですが、可能でしょうか？

Frameworks and Libraries に

Accelerate.framework と,

/usr/local/lib 下の libgivaro, libgmp, liblinbox.dylib を追加
header search paths に /usr/local/include を追加
library search path に /usr/local/lib を追加

cxxSettings に headerSearchPath で /usr/local/include を入れてみたのですが、絶対パスは指定できないようで… Package.swift は以下の通りです：

import PackageDescription let package = Package( name: "ClosedRegion", dependencies: [ ... ], targets: [ .target( name: "LinBoxWrapper", // これが C++ ライブラリの wrapper dependencies: [] ), .target( name: "ClosedRegion", // これがプログラム本体 dependencies: ["...", "LinBoxWrapper"]) ], cxxLanguageStandard: .cxx11 )

C++ のライブラリは含まれておらず、ビルド済みのものが /usr/local/lib 下にある状況です。これが Xcode を立ち上げる必要なく swift run だけで走るようになるとさらに嬉しいです。 (edited)

こちらがレポジトリです。 https://github.com/taketo1024/ClosedRegion

taketo1024/ClosedRegion

Contribute to taketo1024/ClosedRegion development by creating an account on GitHub.

（昔は otherCompilerOptions: ["-I", "/usr/local/include"]）とか出来たっぽい…？

 .target( name: "LinBoxWrapper", dependencies: [], cxxSettings: [ .unsafeFlags(["-I", "/usr/local/include"]) ], linkerSettings: [ .linkedFramework("Accelerate"), .unsafeFlags(["-L", "/usr/local/lib"]), .linkedLibrary("linbox"), .linkedLibrary("gmp"), .linkedLibrary("givaro") ] ),

これで出来てそう！ (edited)

swift run でも実行できました！

2

皆さん色々と教えて下さりありがとうございます

unsafeFlagsを使ったやつ、unsafeFlagsを使ってるFooそのものじゃなくて、Fooに依存してるCFooの方を利用しようとしたら、MergeSwiftModuleのフェーズでエラーになりました（なお、"App"はiOSアプリで、Xcode 11 beta 4で試しています）

2:48 AM

<unknown>:0: error: error opening '(...ProjectのDerivedDataのパス...)/SourcePackages/checkouts/Foo/Sources/CFoo/include/Foo-Swift.h' for output: Operation not permitted

2:49 AM

なお、Fooそのものの方を利用しようとしたら（ObjCからは呼び出せないことは覚悟の上で試しにやってみたら）、サクッと次のような感じのエラーになりました。

error: The package product 'Foo' cannot be used as a dependency of this target because it uses unsafe build flags. (in target 'App' from project 'App')

2:51 AM

でもまあFoo-Swift.hを更新するためだけの、パッケージ外に公開しないターゲットを作っておけば、Fooの開発中にそちらのターゲットをビルドすることで自動的にFoo-Swift.hを作れそうなので、運用面はだいぶ改善される気がします。まだそちらは試してませんけど。

試してみようとしたけど、それはダメでした。FooDevelopというターゲットを作って、path引数でSources/Fooを指定してunsafeFlagsをつけようとしたけど、ソースファイルがoverlapしてると言われた

ソースファイルがoverlapしてる

そんなチェックも入ってるのか。

3:33 AM

Foo-Swift.hを更新するためだけの、パッケージ外に公開しないターゲット

別のターゲットではなく、環境変数でunsafeFlagsが有効になる様にするとか。

1

ObjC → Swift はSwiftPMだと微妙なんですねえ

SwiftPMでObjCのパッケージも作れそうだから、そもそもFooをObjCで書けば罠は踏まないかもしれない（いやだ）

呼ばれるSwift側が単純なfuncとかならそれほど問題にならないけど、型を使うとかだと面倒ですね。

@norio_nomura 環境変数で unsafeFlags を有効にする方法ってあります？やってみようとしたら見つけられなかったので。

こんな感じ。

// swift-tools-version:5.0 import PackageDescription import Foundation let package = Package( name: "Foo", products: [ .library(name: "Foo", targets: ["Foo"]), .library(name: "CFoo", targets: ["CFoo"]) ], targets: [ .target(name: "Foo", swiftSettings: { ProcessInfo.processInfo.environment["UPDATE_SWIFT_HEADER"] != nil ? [.unsafeFlags(["-emit-objc-header-path", "Sources/CFoo/include/Foo-swift.h"])] : [] }()), .target(name: "CFoo", dependencies: ["Foo"]) ] )

(edited)

おお！Swiftだから、そこでそんな風に書けるんですね！思いつきませんでした！

SwiftPM的にはCターゲットがSwiftターゲットへ依存してる事まで理解しててコマンドは全部抑えてるんだから、SwiftPMに機能追加すればスッキリ解決しそうだな。

上記コードは動作確認していません。クロージャにしなくてもいける気もします。

3:57 AM

PackageDescriptionモジュールにもっと簡単に環境変数へアクセス出来る仕組みがあっても良い気もします。 (edited)

環境変数のやつ、クロージャーは要らないですね。それと、環境変数が定義されていないときの [] はempty list not supportedって言われるので nil に変更。これで動くことは動くようです

11:35 PM

ただし、Xcode (11以降) で開発するつもりなので、そうするといつどこで定義した環境変数が生きてくるのかよくわからず

11:41 PM

export UPDATE_SWIFT_HEADER=1;open /Applications/Xcode_11_Beta_4.app でXcodeを起動するのはあんまりだ（これでいちおう動くことは確認しましたが）でも、CIで使うにはいい方法だなと思いました。

いや、CIでやるなら、Package.swiftはいじらずに、swift buildに -Xswiftc -emit-objc-header-path -Xswiftc Sources/CFoo/include/Foo-swift.h を付けて呼べばいいだけのような気がしてきました

(edited)

12:04 AM

↑と思ったけど、依存パッケージのビルドにも -emit-objc-header-path が使われてしまうのでダメです。

--enable-test-discoveryオプションつけるとLinux用のテストファイルを自動生成する？機能が使えるらしい。良さそう https://github.com/apple/swift-package-manager/pull/2174/

This is a WIP PR for implementing test discovery on linux using indexing data. The basic idea is to leverage the IndexStore library to get the test methods and then generate a LinuxMain.swift file ...

それ結局SourceKitを使わずにIndexStodeDBで実装してるのですよね。

そうみたいですね。まだ全部読めてないけどIndexStore使ってますね。

IndexStore学ぶとリッチなインテグレーションツールが作れるんかね

コンパイラが生成する、ソースコード中のシンボルの位置情報を扱うDBだったかな？SourceKitみたいにリッチな情報は得られないけど、テストメソッドかどうかのフラグは含まれてるから、--enable-test-discoveryにはSourceKitより向いてる。

へーそうなのか。IndexStodeDB自体も見てみよう

#linux-swift で一月ほど前に少しだけ調べました。

3:54 AM

コンパイラがテストメソッドかどうか判定するコードまで辿った記憶があるけど、リンクとか残してなかった。

ほんとだ。#linux-swift 読んだ気もするけど完全に記憶から飛んでました

SourceKitみたいにリッチな情報は得られない

あら、そうなのか。

3:57 AM

おや、Discordに引用文法実装されてる。

1

3:57 AM

引用引用

XCTestCaseの孫クラスで、親クラスで定義されたテストメソッドを見つけてくれない、という制限が--enable-test-discoveryにはあった気がするけど、対応されたのかな？ (edited)

3:59 AM

おや、Discordに引用文法実装されてる。

Safariリロードしたら有効になった。

Xcode 11 beta 4付属のswift testでerror: use of unresolved identifier 'XCTUnwrap'エラー。

8:06 AM

回避方法

$ MISSING_LIB_PATH="$(xcrun -sdk macosx -show-sdk-platform-path)/Developer/usr/lib" && swift test -Xswiftc -I -Xswiftc "${MISSING_LIB_PATH}" -Xswiftc -L -Xswiftc "${MISSING_LIB_PATH}"

swift package init --type executable で作った target は，対応する testTarget から import して直接テストするようなことはできないんでしょうか？自動生成されたテストでは、プロセスを実行して出力された文字列をテストするようなものになっているようです．

testTargetってそれ自体がexecutableなのでできない気がします。

5:44 AM

あ、

5:45 AM

executableをテストか。向きを読み違えました。

5:45 AM

XcodeでGUIで設定するときはアプリとかでも普通にテスト対象にできるんで仕組み上はできそうだけどSwiftPMでやってみたことはないから僕はわからないです

やるならテストしたい部分をライブラリとして分けるって感じですかねぇー

それが無難だと思います。というか全部ライブラリに入れちゃって、executableはmain.swiftだけにするというのを僕はよくやってます

5:51 AM

https://github.com/omochi/xcbox/blob/master/Sources/xcbox/main.swift

omochi/xcbox

Create temporary sandbox xcode project quickly. Contribute to omochi/xcbox development by creating an account on GitHub.

5:51 AM

↑例

了解です、ありがとうございます

https://forums.swift.org/t/swift-package-manager-on-windows-sure-why-not/27884

Swift-package-manager on Windows? Sure Why Not!

Hello Swift users, There seems to be a constant question of when will swift-package-manager be available on Windows. Well, Foundation has been under intense development on Windows and is nearing the point where it is on parity with the Linux platform. The last of the area ...

9:11 AM

SwiftPMそろそろWindowsもいけそうらしい

おお

これXcode11 beta3だとビルドできるけど、swift-tools-version:5.1でswift buildすると$SDKROOTは解釈されないんですよね。そのうちswift buildでも解釈できるようになるんだろうか。

 .target( name: "Clibxml2", // Headers and linking for libxml2 cSettings: [.headerSearchPath("$(SDKROOT)/usr/include/libxml2")], linkerSettings: [.linkedLibrary("xml2")] ),

(edited)

ならないと思う。

SwiftPMはなるべくビルドの再現性が高い設計を目指してるから、外部の環境変数を自動で展開する機能は導入しなさそう

Xcode 11 beta 5ではエラーになる。

the build setting 'headerSearchPath' contains invalid component(s): $(SDKROOT)

xcodebuild自体が$(SDKROOT)を使えなくなったってことですか？

なるほど、ここで取られてたアプローチだったんですけど、beta5で動かないんですね。 https://github.com/cezheng/Fuzi/blob/master/Package.swift

cezheng/Fuzi

A fast & lightweight XML & HTML parser in Swift with XPath & CSS support - cezheng/Fuzi

Package.swift内で使えなくしたみたいですね。意図せずXcode 11で使えていたのかと。 https://github.com/apple/swift-package-manager/pull/2206

[PackageLoading] Diagnose invalid values of build settings by acii...

rdar://problem/52395869

1

これXcode11 beta3だとビルドできるけど

これは当然、 $ swift build では元々動かなかったんですよね？

2:13 AM

$ swift package generate-xcodeproj で生成したxcodeprjで使えた、もしくは、 Xcode11のPackage.swift直接開く機能経由で使えた、という意味ですよね。

はい、その通りです。genarate-xcodeprojで作った時にだけ使えたのを確認してます。

どうもです。 generate-xcodeprojはあくまでswift buildの挙動をxcodeで再現するものだと思うので、使えないようにするのが正しそうです。まあ、ちょいちょい差があって苦労しますけどね・・・

今はこんな感じにビルドしてたので、パスをハードコードせずできないかな？と思って、色々試していたのが動機でした.. swift build -Xcc -I/usr/local/Cellar/libxml2/2.9.9_2/include/libxml2 (edited)

あれ？pkgconfigとか使えないんだっけ？

pkgConfigを指定してはいるんですが

 .systemLibrary( name: "Clibxml2", pkgConfig: "libxml-2.0.pc", providers: [ .brew(["libxml2"]), .apt(["libxml2-dev"]) ]),

Xccでフラグ渡さないと、ヘッダが見つけられないんですよね。

/usr/local/Cellar/libxml2/2.9.9_2/include/libxml2/libxml/chvalid.h:17:10: error: 'libxml/xmlversion.h' file not found #include <libxml/xmlversion.h>

(edited)

$ pkg-config --cflags libxml2 でパスが出ない状況ですか？

pkg-config --cflags --libs "libxml-2.0 > 2.6.17" ならパスがでますが pkg-config --cflags --libs "libxml-2.0 > 2.6.17" -I/usr/include/libxml2 -lxml2 $ pkg-config --cflags libxml2 では出ないですね

Package libxml2 was not found in the pkg-config search path. Perhaps you should add the directory containing `libxml2.pc' to the PKG_CONFIG_PATH environment variable

(edited)

なるほど・・・

11:09 AM

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/libxml2

11:10 AM

ここらへんってsystemFrameworksで通す方法がなんかあるのかな

11:11 AM

pkg-configはbrewで入れてると思うんで、brewで入れたlibxml2だったら、pkg-configで見つかると思うんですが

11:11 AM

/usr/includeのやつはどこから来たんだ

brewがみているpkgConfigがusr/indude前提になっていたような

/usr/local/Homebrew/Library/Homebrew/os/mac/pkgconfig/10.13/libxml-2.0.pc これっぽい

11:12 AM

なんだこりゃ。

11:12 AM

macに同梱されてるライブラリのpcファイルをpkg-configのbrewパッケージが独自に用意してるのかな。

https://discourse.brew.sh/t/macos-mojave-doesn-t-install-headers-in-usr/3865

11:13 AM

ここらへんの話ですかね。https://github.com/Homebrew/brew/issues/5068

pkg-config files on 10.14 assume headers in /usr/include · Issue ...

Please note we will close your issue without comment if you delete, do not read or do not fill out the issue checklist below and provide ALL the requested information. If you repeatedly fail to use...

確かにSwiftPMのsystemLibraryはpkg-config用っぽいですね

11:14 AM

一方、macOS SDKとかに入ってる方は、UIKitとかと同じ枠だと思うので、何もしなくてもimportできてくれという気持ちになる・・・

11:15 AM

↑その話っぽいですね。そのpcのポリシーが実態とあってないから機能してないんすね。

11:15 AM

$SDKROOTが書きたい気持ちがわかってきました。

11:15 AM

mac/iOS両方対応しようとすると、xcode-selectだけじゃ対処できないし。

今swiftpmの入門本を技術書典向けに書いてるんですが、ここでひたすらハマっている感じですね調べるほどsystemLibraryの現時点での辛さが.. (edited)

https://qiita.com/_tid_/items/bb1b504b28d80153937b

SwiftPM ライブラリとシステムモジュールを作る方...

SwiftPMでは2種類のパッケージを作れます。

ライブラリ

一般的なライブラリを作成します。例えばAlamofireや[Kingfi...

11:16 AM

こっちの、SwiftPMパッケージとしてシステムライブラリパッケージを作る方式の方なら

11:17 AM

いける気がします

あー古いやりかたのほうですね、試してみます (edited)

https://github.com/apple/swift-nio-extras/blob/master/Package.swift

apple/swift-nio-extras

Useful code around SwiftNIO. Contribute to apple/swift-nio-extras development by creating an account on GitHub.

11:20 AM

↑swift-nio-extrasの中に、libzをリンクしてるところがありました。

11:21 AM

これを見る限り、ターゲットの記述は .target(name: "CNIOExtrasZlib", dependencies: [], linkerSettings: [ .linkedLibrary("z") ]), で

11:21 AM

/Sources/CNIOExtrasZlib/include/CNIOZlib.h で #include <zlib.h> してるだけっぽいので

11:22 AM

やっぱりSystem同梱ライブラリは何も書かなくてもincludeできる気がします、この、間接パッケージを一回書けば。

おお、別パッケージってgitリポジトリ化する必要があると思ってたんですが、linkedLibraryに指定するんですね。これならmac/iOSでも動くのかな。↑の方法でも相変わらずでした。

/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/libxml2/libxml/HTMLparser.h:15:10: error: 'libxml/xmlversion.h' file not found #include <libxml/xmlversion.h>

(edited)

いつのまにかリポジトリ分割はいらなくなってましたね

1

なるほど、MacOSX10.15.sdk/usr/include/libxml2/module.modulemapとか見ると、簡単にはいかなさそう。

11:51 AM

module libxml2 [system] [extern_c] { // Add "-Xcc -I$(SDKROOT)/usr/include/libxml2" to OTHER_SWIFT_FLAGS in Xcode project.

headerSearchPathの話が出てた。 https://forums.swift.org/t/build-setting-headersearchpath-contains-invalid-component-s-srcroot/27960

Build setting 'headerSearchPath' contains invalid component(s): $(...

After upgrading from Xcode 11 beta 2 to Xcode 11 beta 5, we started seeing swift package generate-xcodeproj /Users/paulbeusterien/gh5/firebase-ios-sdk: error: manifest parse error(s): the build setting 'headerSearchPath' contains invalid component(s): (SRCROOT) Package...

1

Swift で C 製のシステムライブラリを使う方法として .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 にはこの設定が反映されないようです

(edited)

Xcode では手動で Library Search Paths を追加してねってことにするのがいいですかね

（まだ他に誰も使ってないけど）

ライブラリが依存する別のライブラリのリンク先ってswiftpmでうまく伝播させられない気がします

2:21 PM

まあ使う側が環境整えてね、でもおかしく無い気はしますシステムライブラリはパッケージの外側にあるので。

2:22 PM

あ、でも、

2:23 PM

ちょうどここのログの上にある、もう一つのシステムライブラリの取り込み方だとどうですか？

もう一つのシステムライブラリの取り込み方

どなたの発言ですか？（というか思いっきり .systemLibrary の話してましたね

）

CNioExtraZLibのやつです

system-module を作る方法？

↑swift-nio-extrasの中に、libzをリンクしてるところがありました。

この話のところ。

2:46 PM

システムモジュールを作ると言っていいのかよくわかんないですが、システムライブラリを参照させるためだけのCターゲットを作る方法です

その C ターゲットに何らかの方法で library search path を与えないといけないですよね？

あー、そうですね、結局同じ問題になりますね

3:13 PM

zlibのやつはSDKでパスが通ってるから良かったけど。

パッケージ下のパスしか指定できない制約、不便なだけでそんなにありがたいことなさそう

rubyとかnodeのネイティブモジュールには結構苦しめられてるので、その辺保守的なのはアリだと思ってます

3:40 PM

10の便利の代償に100のトラブルが付いてくるイメージ

3:41 PM

実際swiftpmの依存先ビルドでハマった事はまだほぼない気がする

なるほど〜

https://github.com/kishikawakatsumi/IBPCollectionViewCompositionalLayout/pull/76 SwiftPM対応した。３つのパッケージマネージャに対応するのはなかなか大変だ。そろそろビルドできるかどうかくらいのテストは必要。。。

2

9:23 PM

https://swiftpm.co/ というパッケージを検索できるサイトが最近できたんだけど、自薦他薦どっちもOKでPRを送るだけ。 https://github.com/daveverwer/SwiftPMLibrary

dependency-mirroringを試してるんですけど

$ swift package config set-mirror \ --mirror-url https://github.com/kishikawakatsumi/KeychainAccess \ --package-url https://github.com/tikidunpon/KeychainAccess

こうしても必ずmirrorの方がはじめにcloneされる..forkには対応していない？ .package(url: "https://github.com/tikidunpon/KeychainAccess", from: "3.0.0"), beta3だからかな、beta6同梱の方で後で試すか (edited)

あ、mirrorがcloneされるのが正しい動きなのか。https://github.com/apple/swift-evolution/blob/master/proposals/0219-package-manager-dependency-mirroring.md#proposed-solution

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - apple/swift-evolution

SwiftPM、もう一つディレクトリの構造によってモジュールを規定していくの便利じゃないんですよね。ルールがある割に結局Package.swiftにもほとんど書かないといけないし。

ディレクトリ構造で規定できたら楽で良かったけど、実際は逆で、 Package.swiftで.targetを書くのが規定する方で、「ターゲット名のディレクトリにソースを入れておく」だけじゃないです？

8:00 AM

.targetを書かないで済むパターンもありましたっけ

ないと思います。そうか、考え方が逆なのか。

そう思います。

8:02 AM

いずれにせよ、なんかめんどくさいので楽になってほしい。Xcode11でSwiftPM対応したから、メニューから作れたらいいのかな。

Xcode 11でパッケージを作り始めることはできるのでそれはすごい便利。

SwiftPMのpackage descriptionにfunction builder使うの提案してみた。 https://bugs.swift.org/browse/SR-11432 自分で実装して使ってみて、正直そこまで大きなメリット無い気がしてきたw 全然実装は途中だけど一旦チケット起票してみたので、なにか意見やアイデアあればどうぞ

見てみると微妙だ・・・カンマ要らないのはいいけどなんで微妙なのか考えてみたけど、 function builderはUI定義みたいに、コンテンツ定義の順番とか入れ子とかが意味を持つようなドキュメント的なものの定義の構築で便利で (edited)

4:00 PM

package.swiftはそういう要素は無いし、型推論組み合わせてドット記法で書けるメリットも失われてしまう

そうなんよねー。function builder使ってドット記法でかけるように変更はできるけど、型推論の部分が失われるのがどうしようもない。現状の方法だとコードの行数も増えるし微妙だという感想しかない... (edited)

Function Builderが嬉しい場面って、雪だるま式に型を定義出来る事で、関数を走らせなくても型によって確定できる部分があるとき、なので

1:44 AM

package descriptionは噛み合わないかもですね

その通りだと思う。function builderで実現できるdeclarativeという点に注目してpackage descriptionに使ってみたけど、本来の目的はこれだと思った

雪だるま式に型を定義出来る事で、関数を走らせなくても型によって確定できる部分があるとき

つまり型定義と関数の実行を分離することにメリットがないと、嬉しさが減っちゃう

そうねー。SwiftPM以外では設定項目を記述するymlとかもfunction builderで置き換えられるかとか妄想してたけど、たぶん同じように意味ない気がしてきた

CatalinaでXcode 11が選択された状態で、swift-5.0.3-RELEASEツールチェインのSwiftPMがmanifest parse errorで動かない。

$ xcrun --toolchain org.swift.50320190830a swift test /Users/norio/github/SwiftLint: error: manifest parse error(s): <unknown>

2:06 AM

swift-4.2.4-RELEASEのSwiftPMは動く。

CatalinaでXcode 10.3を選択しても、やはりswift-5.0.3-RELEASEツールチェインのSwiftPMはエラーになる。

僕がダウンロードしたswift-5.0.3-RELEASEは署名がおかしかったらしい。再度ダウンロードしてインストールし直したら直った。

swiftpmからlibxml2に依存できない問題,bug reportあがってた https://bugs.swift.org/browse/SR-11427 (edited)

SwiftPMで昔あった Package@4.swift みたいな仕様って今もありますか？文書が見つけられず。

9:24 AM

今困っている事は、 Swift4とSwift5で一つのパッケージを共有したいのだけど、 Swift5で導入された.platforms: [.iOS(.v12)]を使いたいけど、 Swift4はその定義ができない、というもの。

https://github.com/apple/swift-package-manager/blob/master/Documentation/Usage.md#version-specific-manifest-selection 見つけました。

https://forums.swift.org/t/draft-proposal-package-resources/29941

The Package Manager for the Swift Programming Language - apple/swift-package-manager

10:12 AM

@omochimetaru

おお！

Draft Proposal: Package Resources

Hi, Some of us have been iterating on a proposal for adding support for resources in Swift packages. I'd like to start a discussion and get community feedback on the design. The latest proposal is always available here. Package Resources Proposal: SE-NNNN Authors: Ander...

9:13 AM

リソースプロポーザル

ファイルの種類に応じてビルド時に処理を挟む機能が設計に入ってる

9:27 AM

XIBとかも対応するためみたい。

9:27 AM

Extensionの話はいったん先送りにしてlibSwiftPMからできるみたいな感じか？

一番上にResourcesディレクトリを作るイメージだったけど、Sources/Hogeに一緒に置くのかな

##Rules for determining resource files … For example, SwiftPM already recognizes files with suffixes such as .swift, .c, .s, etc as source files, and has built-in rules to determine which build tool to invoke for each known type of source file.

あれ？いつの間にか.sがサポートされてる？ (edited)

あ、たしかに。

10:26 AM

しれっと書いてあるけど知らなかったです

以前は対応してなかったはず。

ほおー

10:27 AM

てか、クロスプラットフォームとかどうなるんですか？sファイルってCPUによるけど、

10:27 AM

arm用とx86用を別で置いといて読み分けさせたりできるのか

10:27 AM

自分でPackage.swift側で分岐させるのかな

https://github.com/llvm-mirror/libunwind これをSwiftPMでビルドしようとして出来なくて、.Sを.cppにasm()で埋め込むとかしたことがある。

llvm-mirror/libunwind

Mirror of official LLVM libunwind git repository located at http://llvm.org/git/libunwind. Updated every five minutes. http://llvm.org - llvm-mirror/libunwind

なるほど

10:30 AM

cppへの埋め込みであれば内部でプリプロセッサで分岐させたりはできそうだ

~~うーん、swift-DEVELOPMENT-SNAPSHOT-2019-10-14-aでも対応してない様に見える。~~ (edited)

あいや、// swift-tools-version:5.0でサポートされてた。

let package = Package( name: "Resources", targets: [ .target( name: "Resources", __resources: [ .copy("foo.txt"), ] ), ] )

3:11 AM

https://github.com/apple/swift-package-manager/pull/2386

[Build] Add support for building resource bundles by aciidb0mb3r ...

This adds basic support for building the resource bundles.

3:12 AM

アンスコ付きだけどマージされたっぽい（アンスコ外しはproposal review後だろう）

3

これはいいですね。Xcode 11.3か4くらいに入ってほしい。

11.4ぐらいなら入ってるかもしれませんね

つまり年始くらいにはほしい。

https://twitter.com/aciidb0mb3r/status/1193346451734028288

Ankit Aggarwal (@aciidb0mb3r)

Finally found some time to hack on swift-api-digester integration in SwiftPM

2

3:47 AM

↑SwiftPMでAPI Diffs自動生成らしい

いいんじゃないかな。

これフォーラムで書かれてた妄想があってこれができるとsemver自動検証ができるんですよね

7:50 AM

下位互換切れてるからメジャーバージョン上げなさい！みたいな。

なるほど。それは実現するとうれしいですね。

semverってみんなが守ってないとあんまり機能しないから

8:01 AM

でもみんなが守るには仕組みが必要だと思うんで、発展したら面白そう。

人間は守るつもりはあっても、うっかり見落とすことが十分あるから、それを指摘してくれるのはとてもいいと思うんですよね。

リソースのレビュー終わってた！ https://forums.swift.org/t/accepted-with-modifications-se-0271-package-manager-resources/31021

[Accepted with Modifications] SE-0271: Package Manager Resources

Hello Swift Community, The review for SE-0271: Package Manager Resources ran from November 12th through November 19th, 2019. You can find the review thread here. The feedback was positive, but two larger issues were brought up: the proposal states that resource bundles w...

3

そういえばBinary DependenciesがAcceptされてました。 https://github.com/apple/swift-evolution/blob/master/proposals/0272-swiftpm-binary-dependencies.md

SwiftPM support for Swift scripts

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - apple/swift-evolution

SwiftPM support for Swift scripts https://forums.swift.org/t/swiftpm-support-for-swift-scripts/33126 @package(url: "https://github.com/jpsim/Yams.git", from: "2.0.0") import Yams

SwiftPM support for Swift scripts Proposal: SE-NNNN Authors: Rahul Malik, Ankit Aggarwal, David Hart Review Manager: TBD Status: Awaiting implementation Introduction Swift is a general-purpose language that aims expand it's availability and impact on various domains and ...

swift-shみたいなのを本体側で対応するやつだ

1:31 AM

これは進んで欲しいなあ

spm試してるんですが、Xcode 11.4b1未満だと、spmのswiftモジュールってobjcから見えなかったりします?

1

5:40 AM

@import SPMNoModuleNoNamae; でシンプルにそんな奴はいないってエラーになる

5:43 AM

Xcode11.4b1だとちゃんとmodule mapが生成されてるけど

5:44 AM

Xcode 11.3だと生成されない模様...?

5:47 AM

どうやらそういうことっぽい

5:52 AM

https://github.com/apple/swift-package-manager/commit/0a04609b4f6e5e801a38a729cbffdd89b93b637b

[Build] Generate ObjC compatibility header for library Swift target...

This will generate the ObjC header for library Swift targets so they can be used in other ObjC targets. This is only done for macOS.

5:53 AM

あった、これだ。

わりと最近の対応だったんですね。

Swift 5.2か... なるほどそれで11.4b1必須

5:53 AM

びっくり

5:54 AM

パッチ自体は半年前だけど

__resourcesは5.2では出ないみたいですね。 Remove resources API since it not shipping in swift 5.2 https://github.com/apple/swift-package-manager/commit/046728ad403546070ce9b0d877333d3887bf5d49

Remove resources API and behaviors · apple/swift-package-manager@04...

Remove resources API since it not shipping in swift 5.2

SwiftPMの swift-5.1.5-RELEASE タグが付け直されて、OSSツールチェインも更新されてた。 https://github.com/apple/swift-package-manager/releases/tag/swift-5.1.5-RELEASE

https://github.com/apple/swift-package-manager/blob/master/Package.swift#L38

The Package Manager for the Swift Programming Language - apple/swift-package-manager

spmで、.oか.frameworkかって指定がない場合使う側から決められるのかな？

12:23 AM

プロダクションではstatic linkがいいけどデバッグ中はdylibがいいみたいなことがしたいんだけど。

パッケージ側でproduct定義をそれぞれ持たないと無理なんじゃないかな。

ざっと調べた感じそれっぽくもあるし

9:21 AM

そうでもないような気もしてる

9:22 AM

automaticだとそのproductをbuildできなくなって

9:22 AM

じゃあautomaticってなんだよ感があるんだけど (edited)

9:23 AM

他からの依存関係で決まるのかな？と。

9:23 AM

いまいち理解してない

9:23 AM

ソース読めって話なんだろうけれど。

type: .dynamic なproductがあると .o もビルドされるから、その場合、XcodeだとLink Binary Build PahseでリンクしないでOTHER_LDFLAGSを構成ごとに-framework Fooと-lFoo.oで切り替える事は出来た。

10:18 AM

automatic では .o しか作られないからこの手は使えない。

あー、なるほど

10:29 AM

Swift Package Installation

The Package Manager for the Swift Programming Language - apple/swift-package-manager

10:30 AM

libSwiftPM それ自体がなんかそれっぽい構成になってるんですよね (edited)

10:30 AM

.automaticと.dynamicが両方ある。 (edited)

10:31 AM

なんだかとてもhackな感じがするんですが。

あとサンドボックス環境で動くappだと、Copy Build Phaseの代わりにScript Build PhaseでConfigurationを見てframeworkをバンドルへ入れる様にしないといけないかな。 (edited)

bundleへいれるっていうのなかったでしたっけ。Xcodeそれ自体に。 (edited)

5:35 PM

builf configurationで切り替えるだとできないかもだけど

5:36 PM

target分けるなら良さそうかな、、

5:36 PM

いづれにせよspm側がaudomaticのproductだけじゃだめそう

target分けられるなら、それが良さそう。

インストールサポート https://forums.swift.org/t/swift-package-installation/35728

Swift Package Installation Introduction It would be desirable to simplify the use of executables that have been compiled with swift build and installing the binary, payloads and other requirements into either a global location usable by all users on the system, or make it avai...

https://github.com/apple/swift-evolution/blob/master/proposals/0271-package-manager-resources.md 271とかその他もろもろ（SE-271, SE-272, SE-273 and SE-278）Swift 5.3に来るみたい。

[Build] Add support for building with the integrated Swift driver b...

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - apple/swift-evolution

お〜〜

resources...!

リソースとローカライゼーション、バイナリ形式のサポート、

5:42 PM

Conditional Target Dependenciesって何だっけ？

conditionalにtargetをdependentできるんじゃないですかね

どういうconditionが書けるんだっけ

あープラットフォームによって参照するリポジトリ自体を変えたりできるのか？

platformとか、configurationとか？

5:45 PM

debugはdylib, releaseはstatic的な←これXcodeでターゲットわけないとできない

あ〜。

5:46 PM

いままでだとPackage.swiftの中で無理やりいろいろ分岐して Package() を出し分けてるやつを

5:46 PM

ちゃんとビルドシステムに任せられるんだな。

5.3で実装されるSE多い。 https://apple.github.io/swift-evolution/#?version=5.3

swift/utils/update_checkout/update-checkout-config.jsonにYamsのチェックアウト情報が載る様になってると気づいて調べたら、SwiftPMで--use-integrated-swift-driverオプションとか使える様になってたのね。 https://github.com/apple/swift-package-manager/pull/2736

Add bootstrap and build support for building the new Swift driver and importing it (as a library) into SwiftPM. Then introduce the new SwiftPM flag --use-integrated-swift-driver to enable use of th...

The jobs created by the integrated Swift driver will be merged into SwiftPM's build graph.

3:18 AM

SwiftPMの依存解決とSwift driverの依存解決が統合されていっぺんにllbuildで処理される？

よくわからないけど、そのオプションを付けるとswift package clean後のswift build所要時間が10%くらい短くなるな。 (edited)

本当ですね，確かに速くなってました

もしかして、dorgさんがずっと作ってた、dependency scanと関係あるのかな

https://forums.swift.org/t/llbuild2/36896

Llbuild2

Hi all, Almost 4 1/2 years ago, we open sourced llbuild alongside Swift and the Swift package manager. At the time, llbuild was still fairly new, but it's design has largely stood the test of time, powering SwiftPM builds as well as other products like Swift playgrounds and X...

When combined with llbuild2 support for Bazel's Remote Execution API, this should allow us to start exploring fully distributed/cached builds for SwiftPM packages (when a suitable backend is available).

Swiftでllbuildを書き直すプロジェクト

↑ここが気になる。

9:35 AM

分散ビルド？

です

アツい

9:35 AM

みんなのマシンパワーをオラに分けてくれ」できるようになる？

まさにそれ

xcodebuildも今はnew build system = llbuild だから恩恵乗れそうだな

あとはs3に置いたキャッシュをllbuildが取ってきて途中からビルド再開するみたいなこともできるのかな (edited)

なんでこのタイミングなんだろう

9:38 AM

Apple的に裏の意図は何かあるかしら

Unlike llbuild, which tried very hard to have minimal dependencies, we can be much more open on taking on Swift package dependencies to let us build up functionality faster or in a more maintainable way.

9:40 AM

swift-driverにYamsが使われてたり、Appleのポリシーに変化があって3rd-partyライブラリを使っていく流れがある？

たしかにそのへんも最近ゆるいね。

https://forums.swift.org/t/swift-package-registry-service/37219

Swift Package Registry Service

Hello! Last June, Apple and GitHub announced that the GitHub Package Registry will support Swift packages. A few months ago, Bryan Clark started a thread to gather ideas about a standard package registry API that could be implemented by anyone, not only GitHub. Over the past...

2

セントラルレジストリ形式のほうがいいのかなあ、というのは多少疑問があるけどまああったら便利なのかなあ。

6:18 PM

正直わからん。どっちでもいい気がする。

npmみたいな感じか

6:20 PM

goみたいな感じか...

goもパッケージ登録の仕組みあるんでしたっけ？

あってでも、URLがそのまま

2:04 AM

今のswiftpmみたいな感じ

質問です

4:51 PM

xcshareddata にできる Package.resovled って (edited)

4:51 PM

commitしてますか?

4:52 PM

たぶん使われたgitのSHA1が記録されてるらしきファイル

xcshareddataはcommitする場合もありそう。xcuserdataは絶対しないけど

Gemfile.lockみたいなやつなのかな...?

4:52 PM

xcuserdataはignoreしてますねえ

.lockは基本commitしたい感じがする

packges.json.lock相当だとするとcommit なのかなあと思ったり

4:53 PM

{ "object": { "pins": [ { "package": "KeyboardGuide", "repositoryURL": "https://github.com/niw/KeyboardGuide", "state": { "branch": null, "revision": "f52e9881d8aa9b93dd76b9596e4d2c40a9b99308", "version": "0.2.0" } } ] }, "version": 1 }

4:53 PM

こんな内容

revisionがハッシュですね

ですよねえ

これはcommitしたいかなぁ

.pbxprojとはどういう関係なんだろうか...

4:55 PM

/* Begin XCRemoteSwiftPackageReference section */ 5413B883249A7D32003873A4 /* XCRemoteSwiftPackageReference "KeyboardGuide" */ = { isa = XCRemoteSwiftPackageReference; repositoryURL = "https://github.com/niw/KeyboardGuide"; requirement = { kind = upToNextMajorVersion; minimumVersion = 0.2.0; }; }; /* End XCRemoteSwiftPackageReference section */ /* Begin XCSwiftPackageProductDependency section */ 5413B884249A7D32003873A4 /* KeyboardGuide */ = { isa = XCSwiftPackageProductDependency; package = 5413B883249A7D32003873A4 /* XCRemoteSwiftPackageReference "KeyboardGuide" */; productName = KeyboardGuide; };

4:55 PM

pbxprojにもバージョンが...

4:55 PM

あー、そうか pbxproj にはrequired versionで packages.json 相当で (edited)

4:56 PM

Package.resovled が lock ファイルと。

4:56 PM

これは両方commitっぽいなあ

4:56 PM

SPM libraryそのものの開発とかだとまた違いそう

4:57 PM

(ってそれはXcodeプロジェクトはできないから問題ないのか)

SPMだけならPackage.swiftしか書かないから

ですね

ですです。そもそもgenerate-xcodeprojしてもignoreするし

4:58 PM

確か幾つか前のバージョンからPackage.swift開いたらワークスペース見れるようになってたから

4:58 PM

サンプルプロジェクトぐらいしか使わない気がする

.xcodeprojがない世の中こないかなあ

4:59 PM

来週こないかなあ

xcodegenで頑張るとか

5:00 PM

あれってswiftpmサポートされてるのかな

さすがちょっとにしんどい

対応してるっぽい > xcodegen

ちなみに、最近の Apple のサンプルコードに入ってた .gitignore ファイルは↓のようになってました。

# See LICENSE folder for this sample’s licensing information. # # Apple sample code gitignore configuration. # Finder .DS_Store # Xcode - User files xcuserdata/ **/*.xcodeproj/project.xcworkspace/* !**/*.xcodeproj/project.xcworkspace/xcshareddata **/*.xcodeproj/project.xcworkspace/xcshareddata/* !**/*.xcodeproj/project.xcworkspace/xcshareddata/WorkspaceSettings.xcsettings **/*.playground/playground.xcworkspace/* !**/*.playground/playground.xcworkspace/xcshareddata **/*.playground/playground.xcworkspace/xcshareddata/* !**/*.playground/playground.xcworkspace/xcshareddata/WorkspaceSettings.xcsettings

おおー。

11:08 PM

WorkspaceSettings.xcsettings は無視か...!

先月だったかに公開された↓です。 https://developer.apple.com/documentation/coreml/detecting_human_body_poses_in_an_image

そんな気がしてた

WorkspaceSettings.xcsettings は無視か...!

! が付いてるから ignore 対象ではなく commit ？

無視を無視？

11:11 PM

ignoreを無視

11:13 PM

んー

11:14 PM

/* ってそのレベルだけだっけ

11:14 PM

だから、Package.resovled はコミットなのかな?

.gitignore は無視する（コミットから除外する）ファイルを書くもので、 !**/*.xcodeproj/project.xcworkspace/xcshareddata/WorkspaceSettings.xcsettings のように ! から始まるものは除外対象でなくす（つまりコミット対象とする）じゃないですか？

An optional prefix "!" which negates the pattern; any matching file excluded by a previous pattern will become included again.

https://git-scm.com/docs/gitignore

1:32 AM

なので、 WorkspaceSettings.xcsettings はコミット対象かと。

1:35 AM

このプロジェクトは SwiftPM は使ってないですが、 Package.resolved はコミット対象とするのが一般的なように思います。ただ、↑の .gitignore だと除外されちゃいますね。

だとするとこれもあまりアテにならないというか...

1:39 AM

たまにサンプルコードすごい過ちが入ってることあるから

1:39 AM

なんとも言えない感

1:39 AM

Package.resolved はやっぱりコミットするものですよね

コミットするものだと思います。

私もコミットします

1

みなさまのお力をお借りしたい...

2:20 AM

https://github.com/niw/swift_package_objc_module_failure

niw/swift_package_objc_module_failure

Minimum reproducible project that causes Swift Package Objective-C module build failure on Xcode - niw/swift_package_objc_module_failure

2:21 AM

これなんとかならないでしょうか...?

2:22 AM

なお最新のXcode 12でもダメの模様

問題は再現した

やったー

これTestPackageを、普通にhttpで取ってくる構成にしてもだめですか？

試してないなあ

やってみるか

それでかわったら恐ろしい

@import TestPackage; 実際これが出力されちゃうのが問題みたいですね。PrintAsObjCモジュールのバグな気がする。

ダメだったー

(まあ当たり前か、file:///で参照した)

同じことになった

そう、-Swift.hの@import packageがそんなんしらん、ってなる

2:32 AM

でも、この@importはないと、protocolが存在しなくなってしまう

なんかいつもと変わらない気がするのに何が違うんだ？

もし、@objcされてるのがclassだけなら、foward declearation @class になって、

@objc 付きの protocol があるところか

この@importはでない

2:33 AM

@objcつきのprotocolをconformしているclassがあると、@importがでてしまう (edited)

2:33 AM

そしてそれは正しい(header的に)

2:35 AM

SwiftPMが吐いてるのがSwiftヘッダーだけでObjC向けのものが無いから見えないのかしら

2:35 AM

どっかになんかあるならビルド設定でパス通したら無理やりいけるのかなと思った

ああそうか、これはTestFramework-Swift.h だから、@import TestPackage は必要なのか。

/* 愚痴: 会社の人でSwift嫌ってるというかなんというかそう言う人がいて、絶対Objective-C対応しないとダメだコミットさせないっていって @objc つけまくっていろいろやった結果がこれ... 今日1日これで溶けた */ (edited)

3

SwiftPMじゃなかったらいけるのかしら？

SwiftPMのパッケージ側にmodule mapを置くスタイルにしたらいけるきがする

module mapかー

パッケージ側をSwiftだけで書いたやつAと、ObjCだけのやつB (module map付き)にして、 B → A で依存を組んでホストプロジェクト側はBを取り込む？

SPMじゃなかったらいけると思うけれど、うーん。

2:40 AM

B→Aに@objcいるから、なんか残りそう...

今だと https://developer.apple.com/forums/ で質問するのがお勧めです。

w

2:53 AM

Bいれてみたけどうーん

2:57 AM

Bの.oができただけだった...

おっしゃ〜

3:04 AM

ビルド通せた

1

!!!

3:04 AM

すごい

共有するからちょっとまって

どんな魔法を

うわ〜　整えてたら動かなくなったｗ

1

swiftSettings: [.unsafeFlags(...)] で無理矢理 ObjC用ヘッダを出すとか？ (edited)

ええ

3:07 AM

これでさっきいけたんだけど構成きれいにしたら GeneratedModuleMaps が消えて無理になった (edited)

GeneratedModuleMaps...

3:08 AM

unsafeFlags強そう

3:08 AM

その代わり、重要ななにかができなくなった気がする

SwiftPM内同士だと ObjCから @import TestPackage; できたから (edited)

そこまでは手もとでも試してた (edited)

中間ファイル調べたら GeneratedModuleMaps があったから、それを Test target に -Xcc -fmodule-map-file で読ませる作戦だった

3:09 AM

でもSwiftPMをローカル編集モードから HTTPチェックアウトに戻したら消えちゃった

module TestPackage { header "TestPackage-Swift.h" export * }

3:09 AM

これかあ

あれ？依存が消えてる　これのせいか

3:10 AM

あ〜いけるわ

1

3:12 AM

https://github.com/niw/swift_package_objc_module_failure/pull/1

-Xcc by omochi · Pull Request #1 · niw/swift_package_objc_module_fa...

3:12 AM

とりあえずビルドできるものを共有したつもり↑

3:13 AM

たしかに swiftSettings: [.unsafeFlags(...)] でパッケージ側から注入できたらマシだなあ

お。いけた...!

ライブラリはローカルじゃなくて僕のgithubから取ってくるように書き換わってます。

workaround感あるなあ

そうですね。

-Xcc ｗ

最初、 swift flag と c flag　やったけどだめで

すごい名前のPRきた

swift の -Xcc じゃないといけないっぽいですね

3:14 AM

swift frontend が起動する内部の clang importer の振る舞いだから。たぶん。

それはそうですねー

3:15 AM

Testにswiftがいなかったら多分文句言わない...?

普通のcflagsでも引き継ぐと思ったんだけど。

OTHER_CFLAGS でも試してみるか...

3:16 AM

て試してあるのか、これ。

あ、消し忘れてた

3:16 AM

どっちが効いてるかぐちゃぐちゃになってしまった

3:17 AM

Swift Compiler - Search Paths の Import Paths にディレクトリを指定する方式もやってみたけどダメだった。

3:17 AM

ああ、そもそも import TestPackageObjC　は普通に成功したから (edited)

3:18 AM

TestPackageObjC が import してるモノをエクスポートしてくれたら良いと思って、

3:18 AM

module TestPackageObjC { export * }

3:18 AM

こういうふうにやってみたんだけど、ダメだった

3:18 AM

TestPackageObjCは普通にビルドできるから、依存の依存として見えてもよさそうなんだけど。。

modulemapの扱いがよくわかってない>SPM

3:19 AM

おいといたら使われるというわけでもなさそう

これで通った

おおお！

dependencyが逆向きになっとる・・・

これは、、

3:29 AM

TestPackage.h をつくって、@objcの内容を書いておく...?

ObjC依存って属性がついてなんかうまくいく感じかな

これだと TestFramework-Swift.h には @import TestPackageObjC; が書かれるんですね。

.hに@protocolがあるからかあ

3:33 AM

恐ろしいworkaround...

ああ、問題のprotocolをObjCパッケージに移してるのか。

あ、そうです。

うーん、、

3:34 AM

まあ確かに @objc するなら同じことか...

見かけだけでもSwiftで書きたいなあ。

えー、なんかわりと地獄だなあ。

modulemapは使い方間違っていたのを直して今やってみてるけど

3:35 AM

TestFrameworkがTestPackageObjCをimportする時点でその先のTestPackageが見えなくなっちゃった。

// 愚痴: いやまじ、obj-c対応なんてしなくていいじゃん、、objc-cで使いたい人がブリッジTest側に書けばいいじゃん

TestPackageObjCは単体でビルドできてるのに。

愚痴というかそれは正論ではw

// 愚痴: Swift 嫌いな人には Swift だけの機能が許せないのです (edited)

3:36 AM

// 愚痴: (型推論も邪悪みたいなこと言ってた) (edited)

そういう人には　ほら実質ObjCですよ^^ ってやりたいですよね。 @objc で。

C++で書いたのも全部ObjCで使えるようにするのかな (edited)

// 愚痴: Swift 1のころはまあ同意できる主張もあったけど、Swift 5にもなってそんなこといってて、ちょっとうーんって感じ

う〜やっぱclang importerがシブいなあ

その手の行動はチーム開発として破綻してるのでレビューで吊し上げるしかなさそう

// 自分よりシニアなのでなかなか... 対立するのは得策ではない... (edited)

しんどそう

でも、ObjC分離はありだな。

3:40 AM

実際ほとんど extesnion に押し込んでいつでも消せるようにした

インターフェース部分だけObjCで書いて実装はSwiftでもまあ

3:40 AM

全部ObjCよりは楽か。

ただ、ObjCをswiftから使うのは楽なんだけど

3:41 AM

逆はすごい足枷になってシンドイのでうーん

ビルドもグルグルしててやりづらいですよね

3:42 AM

Swiftが通ってObjCが通ってからSwiftが通るみたいな

3:42 AM

逆だったかな　なんかやりづらい感じになる

サンドイッチは仕方がないかなあ

3:42 AM

現状では。

3:43 AM

でもこれ分離するとしても気をつけないとなにをObjC由来にすればいいのか

ObjC->SwiftはUIKitなどimportしなければならなかったためにいろいろ整っているけど、Swift->ObjCはおまけ機能みたいな感覚はありそう。

1

結構むずい

3:44 AM

forward declarationできないやつだけか

最後に SwiftPackage-Swift.h として Swiftで見えてるものを ObjC ふうにexportするんですよね

protocolだけならまあ許せるかも

3:44 AM

Swift押しでObjcは二軍なので

3:45 AM

ObjCを使いやすくする必要ないんだよなあ

3:45 AM

(ここ数年の傾向)

iOS14 の Widget が SwiftUI 限定だったのが

3:45 AM

そういう界隈では結構インパクトありそうと思った

3:46 AM

今まではObjCでできない事は無かったけど

3:46 AM

Swiftでしかできないことが出てきた。

ですねえ

去年でたやつだと(一昨年か？) Network.framework も Swift or C だったけど。

そうそう

or C なら一応 ObjC でも使えるじゃん〜　って事だったので。

新しいAPIはC/Swiftだった

WidgetのSwiftUI限定は結構おおとなった

1

一応Objective-Cもdirectとか増えたので全くノータッチdeprecatedってわけじゃないんだけど

3:48 AM

恐ろしく冗長なのでそろそろ、、、と言う感じ

7年前に作ったアプリ、ウィジェットとの相性最高なんで流石に作り直すか〜という感じ

3:49 AM

Objective-C++で書かれている…

.mm...!

諸般の事情でC++を使う必要があって.mmなんですよね

3:51 AM

アプリサイズ934.9kbなのでそこに到達できるか楽しみ

3:51 AM

stdlibバンドルしなくて良くなった今ならイケる気がする

そこって？

アプリサイズをkbサイズにする、前まではSwiftだと出来なかったけど

ほお

AppClipの10mbの10分の1だよ

うーん、-Xccでworkaroundして問題解決されるのを待ったほうがいいか

3:54 AM

protocolとかobjcの世界に持っていってしまうか...

3:55 AM

すぐにはなおらなさそうだよなあ

報告したら1年後ぐらいに治りそう

1年w

半年？

今報告して12で治る気はしない

Xcode11からのリグレッションじゃないとなかなか厳しいと思いますね。

1

これ実質SwiftPMで@objcはダメです宣言なんだよなあ (edited)

SwiftPMじゃなかったらいけませんかね

普通のXcodeでFrameworkにしたら大丈夫そうではある

xcodebuildのbuild setting で DEFINE_MODULE = YES にすると modulemap が出てだいたい @import 成功するいめっじ

3:59 AM

いや今もSwiftPMはそれを出してはいるのか、xcodebuildがそれを拾ってくれない

xcode→swift -frontentで渡ってない感じ

これ実質SwiftPMで@objcはダメです宣言なんだよなあ

なんで、ワンチャンねじ込めるかもなーとは思ってます。

パッチあったらいけるかも？

4:01 AM

SwiftPMってbugsのJIRAでいいんだっけ

SwiftPMはbugsでオッケーだけど AppleのほうにXcodeのバグとしても出しておくのがベストそう

rdarはどの場合も必須な感じ

（だめだ〜modulemap作戦はよくわからない、諦めた

ほんと今ならforumに書いたらとりあえず反応のプライオリティ高いっすよ

module.modulemapのswiftpmでの扱いがわからない...

4:03 AM

まずJIRAつくります

4:04 AM

POCあるし

4:04 AM

わりと容易い

include/module.modulemap をターゲットソースに入れておくと、C/ObjCターゲットの場合

4:04 AM

それをモジュールとして構成するときにその modulemap を使う

4:05 AM

もしmodulemapが入ってない時は、swiftpmが勝手にヘッダーディレクトリやmodulemapを作る？んだと思う

まず https://bugs.swift.org/browse/SR-13075

4:19 AM

つぎフォーラム https://developer.apple.com/forums/thread/650935 (edited)

rdarもつくった

4:28 AM

やれることは全部やった... あとは解決策だけ...

えらい

4:30 AM

しばらくは-Xccでごまかして

4:30 AM

もしXcodeとかの振る舞いが変わってその技がぶっ壊れてビルドできなくなったら

うーん

ObjCに切り出す状態にして耐える

しんどい

そのうちXcodeが直ってかいけつ

4:31 AM

ObjC切り出しは先にやっても後にやっても同じだからとりあえずはごまかすのが楽そう

確かに。

4:32 AM

-Xcc あって困ることはない感じか...

あ、もしかしたら

4:32 AM

ObjC切り出しって手書きしなくても

4:32 AM

うまいことObjC側からXcodeで依存を表示してObjCモード表示になれば

4:32 AM

コピペでできるかも？

4:33 AM

っていうかそもそも TestPackage-Swift.h としてテキストで出てくるのか。

protocol以外に該当がなければ

4:33 AM

たやすい

condition: .when(platforms: [.macOS])とかの時に-emit-objc-header相当の設定をPackage.swift内で持たせられる様になれば良いのだろうか。

TestPackageObjCが無いときは、TestPackage-Swift.h は生成されていないのかしら？

4:59 AM

仕組み的にはxcodebuildが TestPackage に依存するときに

4:59 AM

ObjCからもインポートできるようにしなさいねって要求を伝えるべきですよね

あー、今でも生成されてるね。

TestPackageObjCがなくても生成されているなら、いつでも生成されてるから

5:01 AM

単にxcodebuildがそれを見に行かないのが変ってことだ

1

5:02 AM

細かい連携上の設計はしらんからもしかしたらSwiftPM側のアウトプット表明が何かしらバグってるとかはあるかもしれんけど・・・

依存する側をXcodeプロジェクトではなくSwiftPMにしても再現するならば、SwiftPM(llbuild?)の挙動を修正すれば良いのかも。

ふむー、全部SwiftPMなら問題ないかも（問題の直接の解決にはならないし、現実的ではないけれど...） (edited)

5:15 AM

問題の切り分けで試してみる価値はある

XcodeはSPMのtargetがobjcなら、-Xcc -fmodule-map-file=.../GeneratedModuleMaps/... をつけてるなあ (edited)

lol

6:26 AM

I found a solution

お

SWIFT_INSTALL_OBJC_HEADER = NO;

6:26 AM

これを Framework にいれる

TestFramework ?

そうそう

6:27 AM

なんで動くのか理由はわからない

TestFrameworkがSwiftからしか使えなくなりません？

あーそういうこと？

わからないけど。予想。

そうだった...

6:31 AM

だめじゃん

1

そうか、、frameworkの外から見えなくすればいいから

6:43 AM

packageのinterfaceは絶対にinternal以下のアクセスで使う、@objcで露出させないというのを

6:43 AM

frameworkの側で守れば回避できるのか...

おや...

6:51 AM

これはいい回避策かも

6:51 AM

@import TestPackage; って書いた.mファイルをframeworkに足す

6:52 AM

あ、だめか

そもそも、、

7:30 AM

module を static link で使ってる framework を第三者がつかったときに、ヘッダーが無いのは普通で

7:31 AM

ObjCにすると他にある GeneratedModuleMaps とヘッダを見にいっちゃってビルドできるのが変なのか？

7:32 AM

Products の .framework には、SPMにObjCあるなしにかかわらずPackageのmodilemapやheaderは格納されてないし。

お、じゃあ、SwiftPMのターゲットを

7:43 AM

dynamic frameworkに指定すればいける？

依存する側をXcodeプロジェクトではなくSwiftPMにしても再現するならば、SwiftPM(llbuild?)の挙動を修正すれば良いのかも。

依存する側をSwiftPMにした場合、Swiftでimport TestPackageもObjective-Cで@import TestPackage;のどちらも出来た。 (edited)

dynamic frameworkに指定すればいける？

SwiftPMのtype: .dynamicは.frameworkではなく.dylibになる。

1

XcodeとSwiftPMのビルドマニフェストを見ると、どちらもTestPackageのmodulemapを-fmodule-map-file=で渡しているのは変わらないけどmodulemap内でのTestPackage-Swift.hの記述が、SwiftPMはフルパスでXcodeはファイル名だけという違いがあった。 (edited)

寝てた、、

2:06 PM

dylibにしてもダメだった記憶が。

2:07 PM

フルパスじゃないなあ、とは思ったけど、-Swift.hは傘じゃないからかなとも思った

2:07 PM

その場に生成されてるし。

2:08 PM

static library で module を提供する方法と、

2:09 PM

それをframeworkから使う方法っていう基礎がいまいちわかってない

2:09 PM

そしてXcodeもわかってないのかもしてない？

あと、module-map-file ついてなくないですかね？

2:23 PM

そしてそれが原因というかその点ははっきりしてる気がする

// そして現実問題として、会話の結果たぶん@objc を取り除くという結論になりそう

2

forums回答ついてますね。Expected behavior とな。。

お？？

5:36 PM

通知もなにもこない

^ そうなんですよねー。

So you are responsible for passing the -module-map-file here.

(edited)

5:37 PM

まさかのおもちさん正解説

5:38 PM

changing the build setting SWIFT_INSTALL_OBJC_HEADER to NO, because you don't really need the generated ObjC compatibility header in that case.

5:38 PM

そしてまさかこれも正解説

5:38 PM

そうかー

あと、module-map-file ついてなくないですかね？

ああ、確かにViewController.oのビルド時にはついてないですね。

中の人的には仕様ってことなんだけどかなり厳しい

SwiftPMの場合は、TestFrameworkを使うターゲットにも-module-map-fileがつけられてビルドされる。

Xcodeの仕様っていうなのバグでいい気がするんだけどなぁ

forumのスレッド見たら、Objective-Cの場合は同様な依存グラフでも-module-map-fileが使われてて回答されてるSwiftの挙動と違うと、突っ込んでる人がいるね。挙動に一貫性が無いから、バグとして修正されそうな気がする。 (edited)

PaddyMcPat さんは同僚で

12:02 AM

似たようなの問題に直面してて

12:02 AM

今朝議論してた

12:03 AM

https://github.com/patricknixon/spm-transitive

patricknixon/spm-transitive

Contribute to patricknixon/spm-transitive development by creating an account on GitHub.

12:03 AM

良さげなやつができてる

なるほど。

12:04 AM

ところで、このforumのトピックを購読とか出来ないのかな？up voteしておけば良いのだろうか。

これ投稿者にすら

12:04 AM

通知こなくて

12:04 AM

かなりシンドイ

それはきつい

今日は定期的に⌘-Rしてたw

2

> Is there a way to watch a thread with the new forums and have it show up under your profile? No, although this is a much-requested feature (sufficiently requested that there’s no need for you to file your own bug about it).

https://developer.apple.com/forums/thread/650086 (edited)

hahaha

So you are responsible for passing the -module-map-file here.

ええ〜〜〜ｗｗｗ

5:38 AM

Paddyさんのツッコミは良いですね。

Labの予約とった

5:46 AM

明日朝ちゃんと起きないと

Lab来た

うーんイマイチ

swift build --arch x86_64 --arch arm64でユニバーサルバイナリになるらしい。 (edited)

3:31 AM

手元で試すとx86_64しかビルドされない。Xcode 12もUniversal版にする必要があるのかな？

質問です。自プロジェクトに「AboutWindow」をFPMで組み込みました。 ※ https://github.com/DangerCove/DCOAboutWindow　をObjective-CからSwiftに写経したもの。この状態で、自プロジェクトのAppDelegateから、「AboutWindow」のWindowControllerを呼び出すようなボタンを配置しました。「Clean Build Folder→Build for Runnning」でエラーが出ない状態になり、「Run」したところ、コンソールに「[AboutWindow.AboutWindowController loadWindow]: failed to load window nib file 'AboutWindow'.」ってなメッセージが出力されます。 ※因みに、自画面は、ちゃんと表示されます。これは、AboutWindowControllerクラス（NSWindowControllerを継承）の下記コードに不備がある、ということでしょうか？

convenience init() { self.init(windowNibName: "AboutWindow") }

もしかして、"AboutWindow"の部分を、自プロジェクト.xcodeprojと同階層の「DerivedData」に格納されてる、下記として、明示する必要がある…ということでしょうか？

「自プロジェクト名/SourcePackages/checkouts/AboutWindow/Sources/AboutWindow/AboutWindow.xib」

※この場合、「SPMで組み込んだライブラリ内のxibファイル」への相対パス？を取得する、便利なメソッドは存在するでしょうか？

DangerCove/DCOAboutWindow

A replacement for the standard Mac app About dialog. - DangerCove/DCOAboutWindow

AboutWindow っていう xib は Resources として存在してるのかな...? (edited)

12:11 AM

SPMはresourcesにまだ非対応だからなにか手動でしないといけないと思う (edited)

すいません。「Resources」を確認するには、どこを見れば宜しいでしょうか？

なんとか.app/Contents/Resources かな?

"Implemented (Swift 5.3)" なので、 Xcode 12 beta なら、もしかしたら resources 使えるかも？ https://github.com/apple/swift-evolution/blob/master/proposals/0271-package-manager-resources.md

https://help.apple.com/xcode/mac/11.4/#/itcaec37c2a6

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - apple/swift-evolution

そういえば試してないな、それは...

beta が外れる頃には正式に使えるようになりそうですね。 iPhone が 10 月って報道されてましたが、 Xcode や iOS のリリースも遅れるのかな？ (edited)

12:34 AM

例年であればあと一ヶ月半くらいで使えるようになりそうですが・・・。

「自プロジェクト/DerivedData」配下の「自プロジェクト/Build/Products/Debug/自プロジェクト.app」→「Contents/Resources/」に存在するものは、下記になります。「AboutWindow.xib」は存在しません。

自プロジェクト/自プロジェクト/Acknowledgments.rtf
自プロジェクト/自プロジェクト/Credits.rtf
自プロジェクト/自プロジェクト/Base.lproj/MainMenu.xib
自プロジェクト/en.lproj/Localizable.strings
自プロジェクト/ja.lproj/Localizable.strings
自プロジェクト/自プロジェクト/ja.lproj/MainMenu.strings
自プロジェクト/LICENSE.txt

たぶんそれが原因ではないかな。

12:43 AM

spmはaboutwindow.xibをどうしたらいいのかしらないから (edited)

12:44 AM

build phaseにrun script追加して、コピーしてみてはどうでしょうか。

自プロジェクトのbuild phaseにrun script追加、ですね。試してみます。

ですね。

12:46 AM

の、SPMがResources対応してるなら、それを使っても動くはずだけど、Xcode 12b3で対応してるのかどうかちょっとわかってない。 (edited)

「自プロジェクト名/SourcePackages/checkouts/AboutWindow/Sources/AboutWindow/AboutWindow.xib」から、Resources配下にコピーする…って感じのscriptですかね。

ですね

12:55 AM

12:56 AM

に使えるmacroの一覧があるんで、cp -Rp "$DERIVED_FILE_DIR/..." ".../Resource"

12:56 AM

みたいなのbashスクリプトで書けばいいと思います (edited)

let package = Package( name: "namae",

7:40 AM

このnamaeってgithubのURLとか、directoryの名前と一致してないとダメとか制約ありましたっけ (edited)

7:41 AM

なんかそんな雰囲気なんですが

7:41 AM

いまいちそのルールが見当たらない

7:41 AM

swift-package-managerそれ自体が let package = Package( name: "SwiftPM",

7:42 AM

だしなあ...

directoryの名前と一致してないとダメ

それはないはず

一致してないやつを、.target の .dependencies: [] で .product(..., package: "一致してないやつのnamae") に書くとそんなpackageはありませんみたいなこと言われる (edited)

productとpackageはまた別ですよ

packageの部分です

targetのdependencyとは別にその前に、アプリpackageのdepedencyでライブラリパッケージのGitHub URLは指定してますよね？ (edited)

もちろん

7:45 AM

dependencyの"namae"をgithubのURLのpathに一致させると

7:45 AM

見つけてくるっていうかそんなpackageはありませんのエラーは出ない (edited)

そこの不一致は自分でもやった事ある気がするんだけどなあ

dependenciesは .product(name: "Fluent", package: "fluent"), みたいな書き方ありますけどそう言う話じゃないですよね？

その package: に書く文字列が namae だとそんなのねーよって言われるんですよね

7:49 AM

let package = Package( name: "namae", っていうのが github.com/meow/chotto-chigau-namae.git にあるとして。

7:50 AM

うお

7:50 AM

5.1ならいける

7:50 AM

5.2はだめだ (edited)

7:50 AM

mjk

7:50 AM

えー

7:51 AM

これすごいぶっ壊しじゃん

やば

バグなのか、仕様変更なのか...

7:51 AM

一致させたい気持ちはわかる

7:52 AM

これは...

7:52 AM

masterとってきてみるか...

https://github.com/apple/swift-package-manager/pull/2619 これかな

[PackageGraph] Fix package name validation for product target depen...

The package name validation was wrong for product target dependencies (.product(name: "<product>", package: "<package>")) as we were ...

おー、っぽい

7:54 AM

2月かあ

7:55 AM

ふーむ、現状 5.2 は使えないことがわかった

This completely breaks package loading in 5.2 if a package wants to use a product from a dependency that doesn't match the package name of that dependency.

なんか互換性を壊してる割にあっさりマージされてるのが不思議。

7:59 AM

仕様変更ってことか。

仕様変更なのかなあ?

rdar://problem/59821906 これに書いてあるのかなあ。

よめない >_<

あ、でもPackage.swift の記述で5.1だぞ、ということを示したら元の挙動になるのかな？

依存するものすべてが5.2なら

8:05 AM

よい?

8:07 AM

んいや違う

8:07 AM

逆ですよ

8:07 AM

testみるとわかる

8:07 AM

現状のこの一致してないとダメってのがバグでこれは直してるパッチ

8:07 AM

testで5.2がUnBarっていうBarにあるやつをつかってOKってensureしてるわけで (edited)

なるほど。これは直してるのか。

まあ Xcode 12b4の5.3でもまだ直ってないんですけどね...

8:11 AM

https://github.com/apple/swift-package-manager/commit/b25e390e2156f364b1037b3a33eff137e18b2bad

8:12 AM

こっちが5.3のやつ

Danger-Swiftのプラグイン導入した時まさにこれに悩まされてました

どこにもはっきり書かれてなくてでもそういうルールがあってもおかしくないかなーとは思っちゃうのでキビしかった

Package@swift-5.3.swift って書き方があるんですね。Package.swift と両方あったら5.3だとそれを読んでくれるみたい。

10:22 PM

あとXcodeが新しくなったらプロジェクトファイルをアップデートしてくれるやつはPackage.swiftの記述もアップデートしてくれた。そしてかなり賢い。

1

Packge.swift のファイル名に@1xみたいなのがあると...?

あるみたいです。 https://github.com/kishikawakatsumi/KeychainAccess/pull/498 試したところうまくいってるようです。

Fix Xcode 12 warning when depending on Swift package by JosephDuffy...

A copy of Package.swift with swift-tools-version updated to 5.3 and iOS platform updated to iOS 9. Having this as a separate file prevents breaking backwards compatibility with Swift < 5.3 p...

https://github.com/apple/swift-package-manager/blob/cce860c70c3d96d6b21d5f56c06a7edb53996d90/Sources/PackageLoading/ToolsVersionLoader.swift#L41

https://github.com/apple/swift-package-manager/blob/d196d9df58ef0b9067b8343533110e190c6c7997/swift-tools-support-core/Sources/TSCUtility/Versioning.swift#L58

The Package Manager for the Swift Programming Language - apple/swift-package-manager

3:42 AM

The Package Manager for the Swift Programming Language - apple/swift-package-manager

3:42 AM

 public var versionSpecificKeys: [String] { return [ "@swift-\(major).\(minor).\(patch)", "@swift-\(major).\(minor)", "@swift-\(major)", ] }

こんな感じで書けるっぽい。

バージョンコメントやAPI追加ではダメだったんだろうか

https://github.com/apple/swift-evolution/blob/master/proposals/0135-package-manager-support-for-differentiating-packages-by-swift-version.md#version-differentiated-package-manifests SE-0135で意外と早く実装されてたみたいっすね。

https://developer.apple.com/documentation/swift_packages/package/dependency/3582850-package

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - apple/swift-evolution

3:58 AM

提案を見ると、１つのタグ・リポジトリで後方互換性を提供したい、Package.swift内で分岐したりする手段もあるけど、メンテナブルじゃない、みたいな思想のようですね。

3:58 AM

たまに巨大なPackage.swiftあるけど、たいていはそうじゃないからファイル分けた方がいいだろう、って感じなのかな。

なるほど。

Package@swift-*.swiftはSwift 4.0のベータ期間中から使ってますね。 https://github.com/jpsim/SourceKitten/commit/299fcb45aacdf3044212d2c3f549eae096db3225

12:55 PM

もう詳細は忘れたけど、使わないと回避できない状況が結構あった。

意外とパッチ番号までみてくれるからこの方式が一番細かく制御できそう。ファイルが増えすぎるとそれはそれで大変だけど。

SwiftPM、単にiOSアプリをXcodeで作るには簡単だけど、そうじゃないコマンドラインツールとかを作る場合でPackage.swiftを書かないといけない場合、

targets: [ .target( name: "SwiftFiddleEditor", dependencies: [ .product(name: "LSPBindings", package: "SourceKitLSP"), .product(name: "ArgumentParser", package: "swift-argument-parser"), "Ambassador", ]),

のようにターゲットの依存の記述には名前だけでOKなのと名前とパッケージのマッピングが必要なのもの、

let package = Package( name: "SwiftFiddleEditor", dependencies: [ .package(name: "SourceKitLSP", url: "https://github.com/apple/sourcekit-lsp", .branch("main")), .package(url: "https://github.com/apple/swift-argument-parser.git", .upToNextMinor(from: "0.3.1")), .package(url: "https://github.com/envoy/Ambassador.git", from: "4.0.0"), ],

パッケージの記述の方にもパッケージ名を示してあげる必要があるもの、と知らないとけっこう難しいな。エラーメッセージがかなり正確に教えてくれるからいいけど。 (edited)

8:51 AM

リポジトリ名とパッケージ名、ターゲット名を揃えておいたら簡単なのかな。

その辺ややこしいですよね。パッケージのdependenciesのほうでもnameが必要なパターンがあるのは知らなかった。。。

難しい。上でいうとSourceKit-LSPの導入がたぶんいちばん省略しない書き方で、リポジトリに対してパッケージ名をマッピングして、ターゲットのDependenciesでその名前のパッケージ名の特定のターゲットを使う、という意味なのかな。 (edited)

8:54 AM

READMEにはいちばん簡単な書き方しか載っていないので難しい。

dependencies.package.nameを省略したらsourcekit-lsp になって、

8:55 AM

target.dependencies.product.name は sourcekit-lsp でよくなるんですかね？

今のところならないですね。 SourceKit-LSPが提供しているライブラリターゲットを導入するには上記の書き方が唯一の動く記述です。今のところ。

フーム

別の話になるけど .branch("main")) と from: "4.0.0" と.upToNextMinor(from: "0.3.1") とか正直いって型やパラメータ名を分ける必要ないと思う。分かれてても結局文字列で書いたもので決まるわけで。

文字列だと ~ とか <= 　とか使うけど、あれの書き方を忘れちゃうし、ミスするので、 .branch とか .upToNextMinor が補完で出てきて、コンパイルが通れば文法があってる、というスタイルは僕は良いと思ってます。

9:02 AM

ただ、 from: だけはよくわかんないので嫌い。

9:02 AM

たしか upToNextMinor のエイリアス。

9:06 AM

nodejsだと ~ と ^ があったりするけど、どっちがなんだったかもよくわからなくなるし、　そういう意味でも upToNextMinor とかは名前からわかりやすい。

.package(name: "SourceKitLSP", url: "https://github.com/apple/sourcekit-lsp", .branch("main")), .package(url: "https://github.com/apple/swift-argument-parser.git", .upToNextMinor(from: "0.3.1")), .package(url: "https://github.com/envoy/Ambassador.git", from: "4.0.0"),

ちょうどこれがわかりやすいと思うんですけど、一貫性があまりなくてめっちゃ難しくないです？バージョンの指定は from: "4.0.0" と .upToNextMinor(from: "0.3.1") でupToNextMinor外側に書くのか、、、って感じだし、 from: "4.0.0" と .branch("main") もそっちは引数名でこっちは型なの？みたいな。

9:08 AM

NPMやBundlerの ~ や ^ の演算子が覚えられなくてupToNextMinorの方が、というのは完全に同意します。

9:09 AM

ラベルで from: "4.0.0" になるやつは、

9:09 AM

↑この関数で、 Version型が ExpressibleByStringLiteral で・・・

9:09 AM

up to the next major version.

なので、結局

9:10 AM

from: "4.0.0" と書くのは .upToNextMajor(from: "4.0.0") と書くのと同じなんですよね。

9:10 AM

これは僕は利便性よりもわかりにくさが上回ってると感じてます。いらない。

あ、そうでしたか。

.package(url: "https://github.com/apple/swift-argument-parser.git", .upToNextMinor(from: "0.3.1")), .package(url: "https://github.com/envoy/Ambassador.git", from: "4.0.0"),

の２つは一緒か。

ちがいます、 Minor と Majorだから。

違うのか。なるほど。 (edited)

SwiftPMの世界観的には多分、

from: "4.0.0" この書き方できなくていいよね？

メジャーバージョンは勝手に上がったら困るけど、マイナーバージョンは上がってもいいやつだから

9:11 AM

upToNextMajor が一番、ベーシックな指定にしたいんですよ

それはまあ、わかる。

だから、その一番ベーシックな指定にだけ、簡単にかける方法としての from: "4.0.0" が提供されている。

9:11 AM

ただ僕はいらないと思う、わからん。

9:12 AM

で、 .upToNextMajor(from:) と .upToNextMinor(from:) に対して、 .branch() はラベルがないのは、

9:12 AM

まあわかりにくいといえばわかりにくいけど、Swiftの関数は全部そうだし、これはXcodeが補完を出せば問題ないはず。

9:13 AM

Package.swiftの補完は昔は駄目だったけど最近はちゃんと出ませんか？

補完は出るんですけど、Package .swiftを補完で書くのはけっこう難しいですよ。ピリオドをうって出てくる候補がだいぶ多くて、正解を知ってないと選べない感じがあります。

9:16 AM

^ この候補でどれがどれっていうのは難しいでしょ。

たしかにｗ

9:17 AM

versionのrangeでも書けるのか、なるほど・・・

9:18 AM

pathはあれか、ローカルファイルパスのやつか。

.branchとか upToNextMinor が Package.Dependency.Requirement というのはわかったのでわかるけど。

あ、だから、upToNextMinorとかはRangeの ..< を活用しているのかな？

Range<Version> って言われても書けないでしょ、とか。

Versionは ExpressibleStringLiteral だから "1.2.3" ..< "1.3.0" とか書けるんでしょうね。 (edited)

おそらく。

でもたしかに結構わかってないとこれは難しいかも

9:21 AM

https://swift.org/package-manager/

9:21 AM

SwiftPMのPackage.swiftの最大の問題点は

9:21 AM

ちゃんと読めばわかるマニュアルがない事じゃないですかね？

それもあります。いちばん簡単な書き方しか載ってない。

なんか他の npm とかの経験を前提に、勘でわからないといけない

9:21 AM

あとはコードを読むしかない気が・・・

SwiftPMのコードは動かしたことないとエントリポイントがわからなくて詰むな、きっと。 (edited)

ターゲットの依存の記述には名前だけでOKなのと名前とパッケージのマッピングが必要なのものパッケージの記述の方にもパッケージ名を示してあげる必要があるもの、と知らないとけっこう難しいな

これほんとに難しくて、僕は今だに正確な挙動がよくわかってないです。パッケージにモジュール（プロダクト）が複数ある場合とか、省略できるケースとか（リポジトリ名とパッケージ名とモジュール名が同じとき？？）。 (edited)

9:26 AM

まとめられた解説を読みたい・・・。

まとめられた解説

そこの公式文書ないですよねえ。

1

余力があったらREADMEにPRしよかな。

1

9:35 AM

Appendixみたいな形でいろいろなパターンを載せる、とかならそんなに大変じゃないはず。。。

ここに書いてあるかなと思ったけど name については言及されてませんでした

https://github.com/apple/swift-package-manager/blob/main/Documentation/PackageDescription.md

https://github.com/yaslab/CSV.swift/blob/master/Package.swift#L6

The Package Manager for the Swift Programming Language - apple/swift-package-manager

これはどっちかというと提供側のPackage.swiftの書き方の説明っぽいですね。

ですねえ

提供側はたぶんドキュメントや使い方はそれほど難解ではないと思う。自分で作るやつだし、だいたい簡単なパターンから徐々に複雑になるという手順になるからまあわかる。

5.2(ちょっと前まで)と5.3(初期)はバグがあってnameないとダメな気がするってここで発見した気がする (edited)

それを思い出してたんですけど、そのとき私は事象を正しく理解できてなかったようで、ようやく理解できた気がします。

なるほど

なんか前に言ってた名前違うやつっぽいなー、というところから直すのにめっちゃ時間かかりました

バグも絡んでる話なのか

バグ（仕様）

1

Package.swiftはもっと書きにくい、、、みたいなことを書いたけど、Swiftの文法の範囲内でしか書けないのと、わかりにくいけど補完もきくのでDSLとしてはかなり良い。。。と、docker-compose.ymlを書いてて思った。YAMLで書くのは正しい相手が求める構造のYAMLを書くのが難しい。Swiftの文法の範囲でおさまっってるのはとてもいい。

docker-composeのリファレンスといったりきたりしながら書くの結構たいへんですよね。

最近はXcodeでPackageDescriptionの補完がまともに効くようになって更に書きやすくなった印象があります

Package.swiftが書きにくかったのは大体全部補完がなかったせいなので (edited)

11:56 AM

補完あるなら大体問題ない気はしています

YAMLもJSONも補完して欲しい

1

yamlとjsonは補完無いのが当たり前で元から期待値低いからググって書くのは割と平気で

11:58 AM

一方でswiftは補完あって当たり前の期待値なので辛く感じがちなのでは

SwiftPMにYAMLをググって書く時相当の良いリファレンスが無いというのもあるね (edited)

それはありますね

同じレベルでドキュメントがあって、さらにIDEサポートもあれば、YAML以上になるはず

SwiftPMはパターンが網羅されてるドキュメントがあればいける。たぶん私書ける。

そういえば今日、 name指定が必要なproductに出会った

12:01 PM

.product(name: "CSV", package: "CSV.swift"),

パターンがわかっていればいまの補完でかなり強力

yaslab/CSV.swift

CSV reading and writing library written in Swift. Contribute to yaslab/CSV.swift development by creating an account on GitHub.

ああ、.swiftを名前につけるパターンか

Package側に name 指定がある時、

HTTP.swiftとかもダメかな？

ユーザ側で productの package: にそのnameを指定するっぽい。

なるほど

それ難しいよね。相手のPacakge.swiftを見に行かないといけない。

相手のPacakge.swiftを見に行かないといけない

そこ！。

幸いFetchは済んでるからローカルで参照できるけど

手元にチェックアウトしてるんだから何とかして補完してほしい

いや、なんか、そこが間違ってるとエラーになっちゃって、Xcodeのfetchが止まっちゃって、左下に出なかったんですよねｗ

エラーメッセージはかなり的確に教えてくれる。だからQuick Fixももう少しじゃないかな

順番的にfetchだけ成功してそうなんだけども。

あ、Fetchされませんでしたか

fetchだけみたいなコマンドないんでしたっけ

resolveなんとか

12:04 PM

コマンドラインからやる場合そんなのが合った

あるんだけど、

12:05 PM

Package.swift を開いてる時に関しては、そのpackage.swiftが壊れてる場合は、

12:05 PM

左のペインに依存先とかちゃんと出ないっぽい。

12:05 PM

ああそうかXcodeで書いてるのか

なんかXcodeはPacakge.swiftの変更をWatchしてて、めっちゃ積極的にFetchしたがる感じですけどねえ

Reset : 全部やり直す Resolve : Package.resolvedに従ってやりなおす Update : Package.swiftのバージョン指定にしたがってPackage.resolvedも更新する

12:07 PM

そう、watchしてて、間違ってて壊れて、そのname治すまでどうにもならなくなった。

正直、ちょっと見た目を整えただけで、あるのに全部Fetchしようとしたりする、時がありました

編集が完了するまでは Cmd + S 押さないくせが付きつつある

あ、わかった。いったん依存に書くのをやめて、リポジトリだけ書くといいんすよ

あーたしかに

12:08 PM

２段階でやると無難かも

そうすると使われてない、って警告は出るんですけどFetchはおわる

よさそうｗ

エラーが出るのはDependenciesに書いた時なんで、私はいったん一つずつ戻して、、、ってやりながらなんとなくそういうのを体が覚えた

destination.jsonの書き方はこれか。 https://github.com/apple/swift-package-manager/pull/1098

@norio_nomura (edited)

cross compilation support (configurable destinations) by weissi · P...

General This adds experimental support for cross compilation or more precisely configurable destinations for binaries to SwiftPM. The basic idea is that you hand a JSON file in the format described...

1:16 AM

知見

1:19 AM

-Xswiftc よりはよいと思うけれど、Package.swift が DSL で、これは JSON でとなんだかいろいろバラエティにとんできててちょっとアレな気持ち

あとdestination.json内ではパスを絶対パスで指定しないといけないのが微妙。。

1:20 AM

ツールチェーンからの相対パスで指定できるようにして欲しい

絶対パス... ポータビリティがない... (edited)

1

まだ裏技みたいなもんで普通のユーザーが使うアレじゃないんじゃ？

そういえばSwiftPMってPCHっていうのを絶対パスで持ってるのを思い出した。

3:02 AM

ビルドしてからディレクトリを移動すると次のビルドが失敗する。

--helpの出力に載るかどうかで、そのオプションの扱いがわかる様です。--destinationは載ってこない。

なるほどw

なるほど

3:03 AM

クロスコンパイルSwift界隈だと有名

ヘルプに載ってないは確かに裏

意図的に載せる載せないを区別してるとslackで教えてもらいました。

なるほど

swift package completion-tool generate-zsh-scriptの出力には--helpに載ってこないオプションも含まれるので、completionを定期的に更新しておくと補完時に新機能に気づいたりします。

swift-packageには --help-hidden 的なオプションは無いのか

swift package completion-toolの出力はSE-0206 Hashable Enhancementsの影響を受けるので、SWIFT_DETERMINISTIC_HASHING=1を併用するのがおすすめ。

ニッチな知見が集まってきたw

3:17 AM

環境変数で制御できるんですねあれ

ははーん

ホントだctorでチェックされてた

3:18 AM

https://github.com/apple/swift/blob/d21ff5cc0399c3eefdc6e3ba6e402a35743536da/stdlib/public/stubs/GlobalObjects.cpp#L111-L129

apple/swift

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

1

クロスコンパイルSwift界隈w

各プラットフォームに職人がいるんですよ

4:49 AM

AndroidとかArch Linuxとか。

@testable import してても Xcode 上で Enable Testability YES なら Release でテストできるけど、 SwiftPM で -c release でテストする方法ってないんですっけ？

https://github.com/apple/swift-package-manager/blob/f0dcf2a8689421b08111bb17e9a2c477e5190546/Sources/Build/BuildPlan.swift#L951-L962

Implement an Install Command for the Swift Package Manager

The Package Manager for the Swift Programming Language - apple/swift-package-manager

3:20 PM

-enable-test-discovery をつければできる？

おおお、できました！！ありがとうございます。

よかったです

3:22 PM

なんでこういう実装になってるんでしょうね。。。

test-discoveryがあるとLinuxMain？がいらないんじゃないっけ

LinuxMainがあってもtestale importできて良いと思うんですよね

それに関しては --enable-testing だけを有効にするSwiftPMオプションが

3:24 PM

今はないって感じじゃない？

3:24 PM

-Xswift --enable-testing でいけそう

$ swift test -c release -Xswift --enable-testing error: unknown option -Xswift; use --help to list available options Did you mean -Xswiftc?

あ、 -Xswiftc

$ swift test -c release -Xswiftc --enable-testing <unknown>:0: error: unknown argument: '--enable-testing'

ハイフン一つだ

-enable-testing

お

3:28 PM

$ swift test -c release -Xswiftc -enable-testing ならいけた。

それがちょうど、Xcodeで

3:28 PM

あれを設定してる時の状態だと思う。

なるほどー。

コマンドラインのほうで毎回 -Xswiftc　つけるのがめんどうなら Package.swift で unsafeFlags で設定できます (edited)

--enable-test-discovery より -Xswiftc -enable-testing の方が直接的な感じでいいかな？

あー、わかった。test-discoveryがついていると絶対にそのバイナリは出荷されることは無いけど、ただの-c releaseに対してenable-testingつけるとインターフェースが露出したswiftmoduleが出荷される可能性があるからか。

test-discoveryがついていると絶対にそのバイナリは出荷されることは無い

これはどういうこと？

test-discoveryを付けてビルドするのはテストが目的であって、ビルドの成果物に対してユーザーは興味はないので。 (edited)

--enable-test-discovery がついてるとアプリとしては動かなくなるの？

動きますが、enable-testingがついているので意図しないインターフェースが露出することになります。

3:39 PM

swift buildとswift testは別々のコンパイルコマンドを構築しているわけではなくて、llbuildのマニフェストを共有している。よって、swift-test経由で起動したときにはenable-testingをつける、ということをしているわけではなくて、--configuration debug|releaseとか共通のオプションを元にllbuildのマニフェストを構築する。 (edited)

そのあたりは --enable-test-discovery でも -Xswiftc -enable-testing でもどっちでも同じ話じゃない？

3:41 PM

そもそも今の話題って「SwiftPMになぜ　ただの --enable-testing が無いのか」でいいのかな

「どうしてtest-discoveryモードでない-c releaseではenable-testing付きでコンパイルされないのか」のつもりでした

ああ、じゃあ疑問はなかった。

--enable-test-discovery Enable test discovery on platforms without Objective-C runtime これできるなら LinuxMain って何のためにあるの？

要らなくなったという認識

IndexStoreが動かないプラットフォーム向け？

Linux （ Ubuntu ？）では要らなくなったけど LinuxMain が活きるかもしれないプラットフォームがあるってこと？

とりあえず wasm では役に立った

ですね

LinuxMain の Linux とは。

今更変えられない。。。

LinuxMainに相乗りしてるだけのLinuxではないやつ

4:01 PM

そういえば最近出たWindows版はどうなってんだろう？

TestMain とかにして、 LinuxMain は deprecated なエイリアスにしておいて将来廃止とかはできるかも？

Linuxの概念が揺らぐ

1

XcodeのSwiftPMはプロジェクトのフォルダの場所を移動したらパスが変わるからライブラリの取得が最初のチェックアウトからになっちゃうな

Package.swiftの編集はそこそこ難しいから https://forums.swift.org/t/implement-an-install-command-for-the-swift-package-manager/10148/8 そろそろこういうのは欲しいな。

This would be a great addition to the Swift Package Manager. Personally I would slightly favour add as command. Though perhaps install is more common amongst package managers. Being able to use something like … $ swift package add github.com/foo/bar@1.0.0 -t TargetName … w...

1

いつの間にか swift package _format でSwiftPMプロジェクトにswift-formatかけられるようになってた…！

1

マジか

まだアンスコ付いてるからexperimentalっぽいですけど。

4:31 PM

これは便利

そこについてるのちょっと面白い

最高情報

https://github.com/apple/swift-package-manager/pull/2253 swift-format は公式のToolchainには入っていないのでまだ PATH に自前インストールしておく必要があるんですね。 (edited)

[Commands] Add exprimental support for swift-format by aciidb0mb3r ...

This adds a swift package _format command to format all the sources in a package. The swift-format binary will be looked up in PATH and SWIFT_FORMAT. Arguments after -- will passed to swift-format ...

あれ、それって $ swift format と何が違うんだ？

なるほど、SwiftPMにインテグレートされてるわけじゃないのか

パス通してるなら $ swift format が使えるのだから、 $ swift package _format と打っても長いだけ

4:42 PM

パッチの内容的には

4:42 PM

なんかターゲットの定義からソースファイルのリストを取ってくるみたいだ

4:43 PM

ディレクトリに対して網羅的にかけるよりその方がお行儀が良いか。

生でswift formatすると.build/checkoutもフォーマットしちゃうからSwiftPM経由でやるほうがよさそう

.build/checkoutもフォーマットしちゃう

ワイルドだなｗｗｗ

4:43 PM

そのへんのコンベンションはハードコードしてないのか。

いや、嘘かもしれないな。

やってみた。ウオーはえ〜と思ったら大量の > SwiftSyntax parser library isn't compatible < が

www

Xcode 12.0 Swift 5.3 swift-5.3-branch

4:45 PM

これか

DYLD_LIBRARY_PATH で動的リンクするlib_InternalSwiftSyntaxParserを切り替える

4:48 PM

やっぱりデフォルトだと .build/checkout もフォーマット対象ですね。

ウオー動かせた〜

4:49 PM

うわーインデントが２スペだーーーーー

4:50 PM

164 files changed, 12690 insertions(+), 12574 deletions(-)

4:50 PM

今度じっくり設定とか調べよ・・・

4:51 PM

とりあえず動作は早かった

Google スタイルガイド的には 2スペなのです https://google.github.io/swift/

Swift Style Guide

Google's Swift style guide.

generate-xcodeprojで作るxcodeprojのデフォルトは4スペなんだよなぁ

Googleが2スペ派なのは知ってたけど・・・swift-formatのデフォルトそっちなんだ。。

swift-format は主に Google が開発保守しているのですよね。

それも知ってるんだけど・・・それはそれってわけじゃないんですねえ

4:54 PM

Google内部では使ってるのかな

4:55 PM

https://www.tensorflow.org/swift/tutorials/a_swift_tour?hl=ja

スウィフトツアー | Swift for TensorFlow

4:55 PM

S4TFのチュートリは４スペだ。

どっちでも良いから統一してくれ〜〜

4:58 PM

カタカナのスウィフト、新鮮な字面だ

Google は無理やり日本語にする傾向が・・・ https://twitter.com/koher/status/1289038333079744512

koher（こひー） (@koher)

【悲報】FirebaseのAPIリファレンス（日本語）が、メソッド名や引数／ラベル名まで翻訳してしまう。

signIn(with:completion:) サインインも（と：完了:)

https://t.co/goWkqCq6KF

笑

5:20 PM

日本語なんて眼中にないからなー。

5:21 PM

アジアって言ったら中国を意味するしね。

5:21 PM

(非常にリベラル()なベイエリアの話です) (edited)

LinuxMainがdeprecateされそう！ https://github.com/apple/swift-package-manager/pull/3053 (edited)

deprecate LinuxMain.swift by tomerd · Pull Request #3053 · apple/sw...

motivation: Swift 5.1 introduced the --enable-test-discovery flag which instructs SwiftPM to discover tests instead of relying on a test manifest file named LinuxMain.swift. This functionality has ...

2

おっ　この前話してたやつ

swift build --arch x86_64 --arch arm64とするとSwiftPMはユニバーサルバイナリを生成する。この時SwiftPMは、マニフェストを生成してジョブをXcode.app/Contents/SharedFrameworks/XCBuild.framework/Versions/A/Support/xcbuildへ丸投げするぽい。

おー、xcodeバックエンドモードはそこで使われてるんですね

--show-bin-pathは.build/apple/Products/Releaseとかになる。 (edited)

なるほど。ちゃんとプロジェクトローカルに出来るんですね

同じオプションをLinux版へ渡すとerror: could not find executable for 'xcode-select'でエラーになる。

Xcodeがインストールされている夢のLinuxを考慮している。。。

ｗｗ

クロスコンパイルしてlipoするだけだし、SwiftPMネイティブのビルドシステムでも普通に作れそうですけどXcodeでしかできないなにかがあるんですかね

リソース対応とか追加されてるけどそのへんはどうなってるの？

6:53 AM

今の所バンドルに入れるだけなんかな。 iOS向けだと、pngの色変換とかあるから、それをやるならxcbuildがないとたいへんそう

Bundle.moduleのためにコード生成してることしか知らない

あ、Swiftなインターフェースが生えるんだっけ。

Objective-Cのインターフェースも生えます

親切ｗ

このへんと https://github.com/apple/swift-package-manager/blob/9acfcfe1642733c69a297b7ae570891e52389eed/Sources/Build/BuildPlan.swift#L581-L618

The Package Manager for the Swift Programming Language - apple/swift-package-manager

6:55 AM

このへんです https://github.com/apple/swift-package-manager/blob/9acfcfe1642733c69a297b7ae570891e52389eed/Sources/Build/BuildPlan.swift#L426-L470 (edited)

[Makefile] Build swiftlint as a universal binary on macOS by nori...

The Package Manager for the Swift Programming Language - apple/swift-package-manager

fatalError("could not load resource bundle: from \\(mainPath) or \\(buildPath)")

(edited)

6:57 AM

エスケープインエスケープだｗ

とりあえずswiftlintをユニバーサルバイナリにするPRを書いてみた。 https://github.com/realm/SwiftLint/pull/3437

SwiftPM 5.3 uses the XCBuild.framework to generate universal binaries when it receives multiple --arch options. In that case, --show-bin-path returns .build/apple/Products/Release.

@main をつかった main.swift がない executable な Product が swift build できない気がする

8:06 PM

error: executable product 'meowmeow' expects target 'meowmeow' to be executable; an executable target requires a 'main.swift' file

8:06 PM

とか言われるけどほんとは @main な Struct があるから実行できる

8:08 PM

executableProductTargetNotExecutable かな。

8:13 PM

 /// Determine target type based on the sources. fileprivate func computeTargetType() -> Target.Kind { let isLibrary = !relativePaths.contains { path in let file = path.basename.lowercased() // Look for a main.xxx file avoiding cases like main.xxx.xxx return file.hasPrefix("main.") && String(file.filter({$0 == "."})).count == 1 } return isLibrary ? .library : .executable }

8:13 PM

えー...

@available(_PackageDescription, introduced: 999.0) public static func executableTarget(

8:21 PM

使えそうで使えない

8:23 PM

 if targetType == .executable && manifest.toolsVersion >= .vNext && warnAboutImplicitExecutableTargets { diagnostics.emit(warning: "in tools version \(ToolsVersion.vNext) and later, use 'executableTarget()' to declare executable targets") }

8:23 PM

なんかspmが@mainに追いついてない感じ。。。

8:27 PM

https://github.com/apple/swift-package-manager/pull/3045

Support for executableTarget in the manifest, to allow use of `@m...

Implementation of support for executableTarget in the manifest. This allows use of @main by having targets be explicitly declared as executable rather than by looking for particular file names. On...

8:28 PM

タイムリーすぎる、マージされたの23時間前w

そうそう。SwiftPMだと使えてなかったんですよねー

12:34 AM

こういう悲しい感じのworkaroundを使ってた https://github.com/TokamakUI/Tokamak#example-code

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()

TokamakUI/Tokamak

SwiftUI-compatible framework for building browser apps with WebAssembly - TokamakUI/Tokamak

かなしい

12:40 AM

（さっき同じことをした） (edited)

悲しみの連鎖

// TODO: Remove `main.swift` and use `@main` here instead when Swift Package Manager // supports `executableTarget`. // See <https://github.com/apple/swift-package-manager/pull/3045>. // @main

1

12:41 AM

使えるようになってないんかいww

8:36 AM

プロポーザルのリリースマネージャーは誰じゃてか審査期間で誰もつっこまなかったのか

悲しみの連鎖

swift build --arch x86_64 --arch arm64とするとSwiftPMはユニバーサルバイナリを生成する。

HomebrewでClangターゲットを含むSwiftパッケージにこの方法を使うとビルドに失敗する。 Homebrewはclangの呼び出しを乗っ取ってclangへ-march=nehalemオプションを渡す仕組みが入ってる。しかし--arch arm64のオブジェクトファイル生成時にも渡されてしまい、-march=nehalemがサポートされてないオプションとしてエラーとなる。 https://github.com/Homebrew/homebrew-core/pull/66918 (edited)

swiftlint 0.42.0 by jpsim · Pull Request #66918 · Homebrew/homebrew...

Created with brew bump-formula-pr.

Package.Dependency は URL と path 両方とれないんだなあ...

2:04 AM

レポジトリのrootにPackage.swiftがないやつは一回ローカルに別の方法でもってこないと扱えない...

package description の互換性とバージョン番号対応表が欲しい...

Package.resolved をコミットするかどうかってなにかルールあるのかなあ。

5:04 AM

Gemfile.locl 的なものだから

ライブラリならコミットしない、アプリならコミットする、がベストプラクティスだと思ってます

ライブラリだったらコミットせずかな。 (edited)

5:04 AM

やはり。

オフィシャルなテキストがあったかわすれた

まあ雰囲気的にはそんな感じかなと思ってたけど

ライブラリでコミットしちゃうと、ライブラリ同士でANDを取れない可能性が出てきちゃう

5:05 AM

アプリでコミットしないと、ビルド結果が同じにならない

goの人からするとそれが邪悪っぽいけど

どっち？

and取れない

5:06 AM

goのmoduleはなんか全然違う思想でバージョン固定されまくってる

そっちも一理あるとは思います

5:09 AM

ライブラリ作者が検証できるのは実質１つのバージョンだけなので

5:09 AM

範囲指定がうまくいくのは

5:09 AM

依存先のライブラリのsemverが本当にsemverされてるときだけ

5:10 AM

これまでちゃんとしてても、ある日リビジョンアップデートで互換性壊すかもしれないし。

https://blog.golang.org/versioning-proposal

A Proposal for Package Versioning in Go - The Go Blog

Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.

5:15 AM

あとこれかな https://www.youtube.com/watch?v=F8nrpe0XWRg

Singapore Gophers

Opening keynote: Go with Versions - GopherConSG 2018

5:15 AM

そう、goはなんか互換性がぶっ壊れるのはあかんよねっていう感じ

5:16 AM

go module 以前と以降で世界が違ってproxyとかが絡んできてめちゃくちゃ難しいんだけど

5:16 AM

SPMはlockファイルある系なので

5:17 AM

多分Package.resolvedの扱いはライブラリはコミットしない、アプリはする、で正しいと思う。

https://github.com/apple/swift-package-manager/blob/9d5c37a4b8bd956703db3da5d3236c13bbbb4f3b/Documentation/Usage.md#resolving-versions-packageresolved-file

https://github.com/ReactiveCocoa/ReactiveCocoa/blob/master/Package.swift

The Package Manager for the Swift Programming Language - apple/swift-package-manager

6:24 AM

依存先のPackage.resolvedは見ていないっぽい？

1

えっ

Either way, for a package which is a dependency of other packages (e.g., a library package), that package's Package.resolved file will not have any effect on its client packages.

6:35 AM

なに〜

6:36 AM

でもたしかにそれうまい作りな気がしてきたぞ。

6:36 AM

コミットしておけば、ライブラリ自体の開発をするときだけ影響を与えられるし

6:36 AM

もしライブラリの依存先を固定したいのであれば、package.swiftにexactでかけばいいんだし。

ベストプラクティスはspmがやるからユーザーは思考停止全コミットしてどうぞって感じかな

うん、それでうまくいくので、うまいつくりだ

6:38 AM

学び

なんとー

6:39 AM

思考停止

確かにライブラリのテストなんかはQuickのvホゲホゲ使いたい(けどライブラリのユーザが縛られるのは意味解らん)みたいなケースは有り得るから

6:39 AM

良い塩梅に見えますね

なるほどなあ。

6:43 AM

たしかに、一つのパッケージにアプリケーションとライブラリ両方入れられるし

6:44 AM

その場合は？とは思ってた

それはパッケージ分けたほうが良さそうだけど、まあこの仕様だと一緒でもうまくいくのがいいですね。

まあそうだけど、CLIを提供するんだけど、ライブラリでもある、みたいなの結構ある用途だと思う

あー、ありますねえ

CLIもだけど、ライブラリとテストはパッケージ分けるわけにはいかないでしょ。テストはある意味でそのライブラリを利用する最小のアプリケーションでもあるので

アプリをモジュール分割して作ってる時、例えば、

Coreモジュールに ReactiveSwiftをlink
UIモジュールに ReactiveCocoa と Coreモジュールをlink
UIモジュールとCoreモジュールはエンベッデドモジュール

みたいな依存関係をXcodeのSwiftPMで設定してXcodeビルドすると、ReactiveSwiftが重複してるとエラーになるので、CoreモジュールにReactiveCocoaもlinkする対処をしたのですが、上記のような構成にすることはできるのでしょうか？

nisin

アプリをモジュール分割して作ってる時、例えば、

Coreモジュールに ReactiveSwiftをlink
UIモジュールに ReactiveCocoa と Coreモジュールをlink
UIモジュールとCoreモジュールはエンベッデドモジュール

みたいな依存関係をXcodeのSwiftPMで設定してXcodeビルドすると、ReactiveSwiftが重複してるとエラーになるので、CoreモジュールにReactiveCocoaもlinkする対処をしたのですが、上記のような構成にすることはできるのでしょうか？

質問はここのチャネルじゃないだったらすみませんですが

ReactiveSwiftがUIとCoreの両方にリンクされるから重複になってる、のかな。ちょっと違うとしても最終的に１回ずつリンクされるように作る必要がありますね。その解決方法でも良いと思いますし、一番わかりやすいのはアプリの方ですべての依存ライブラリをリンクすることだと思います。

ReactiveSwift が ReactiveCocoa にリンクされてる?

5:25 AM

ReactiveCocoa/ReactiveCocoa

Cocoa framework and Obj-C dynamism bindings for ReactiveSwift. - ReactiveCocoa/ReactiveCocoa

5:25 AM

https://github.com/ReactiveCocoa/ReactiveSwift/blob/master/Package.swift

ReactiveCocoa/ReactiveSwift

Streams of values over time. Contribute to ReactiveCocoa/ReactiveSwift development by creating an account on GitHub.

5:26 AM

んー、どっちもautoだからdnyamicにすればいいんじゃなかなあ。

5:26 AM

autoなproductしかないpackage.swiftでそれをやる方法があるのかどうか...

5:27 AM

でもstaticでもなんかシンボルの衝突は解決されると期待してるんだけど違うんだっけか...

Embedded ModuleをApp Extensionで再利用するために使っているわけじゃなければ、全部static libraryにしてしまうのが楽かなぁ (edited)

↑ appがswift package なら全部staticでちゃんとリンクされた (期待通り) (edited)

5:38 AM

Xcode のプロジェクトの設定の問題な気がする...?

5:41 AM

とくにXcodeでも問題はない

ありがとうございます。参考にして少し設定いじってみます。

1

https://forums.swift.org/t/se-0301-package-editor-commands/44447

SE-0301: Package Editor Commands

The review of SE-0301, begins now and runs through February 15, 2021. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager or direct message in the Swift forums). What goes into a review of a pr...

9:41 PM

これはうれしい

これはいいね。NPMっぽい。

Package.swift が TOML とかでなく Swift であるが故にコマンドで編集した時と手動で編集した時でインデントや改行のルールが違ったりしてヤキモキしそうですね (edited)

自動編集の挙動とXcodeのデフォルトのインデント挙動が一致しててほしいな。

個人的には Xcode より apple/swift-format の方と一致してて欲しいですね... (SwiftFormat 使っている人はさらに別のことを思ってそう)

1:43 PM

あと、特定のフォーマッタに合わせると、そのフォーマッタのどのバージョンに合わせるかという問題が...

たしかにそれは悩ましい

Swiftコードだったらフォーマットするのは簡単だからどっちでもいいけどデフォルトは手間ないほうがいいですね。

https://forums.swift.org/t/pitch-swiftpm-extensible-build-tools/44715

Pitch: SwiftPM Extensible Build Tools

This is a draft proposal for extensible build tools in SwiftPM. It uses some ideas from a previous draft proposal and the discussion that followed, but it is not directly another version of that proposal. Because extensibility is a broad topic and there are a wide variety of needs, this proposal takes the approach of: Providing a way for pac...

2:14 PM

swiftpmのプラグイン仕様の提案

2:16 PM

オーサーにコンラッドさんおる

https://forums.swift.org/t/se-0303-package-manager-extensible-build-tools/45106

SE-0303: Package Manager Extensible Build Tools

The review of SE-0303, begins now and runs through March 12, 2021. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager or direct message in the Swift forums). What goes into a review of a propo...

6:34 AM

プラグイン機能の本レビュー来た

6:35 AM

9時間書き込みがゼロだ

 /// Provides information about the input files in the target being built, /// including sources, resources, and other files. The order of the files /// is not defined but is guaranteed to be stable. /// This allows the implementation to be more efficient than a static /// file list. protocol FileList: Sequence { func makeIterator() -> FileListIterator struct FileListIterator: IteratorProtocol { mutating func next() -> FilePath? } }

なんだこりゃ

import PackagePlugin // This example configures `swiftgen` to write to a "SwiftGenOutputs" directory. let generatedSourcesDir = targetBuildContext.outputDir.appending("SwiftGenOutputs") commandConstructor.addPrebuildGeneratedSourceDirectory(generatedSourcesDir) // Create a command to run `swiftgen` as a prebuild command. It will be run before // every build and generates source files into an output directory provided by the // build context. commandConstructor.addCommand( displayName: "Running SwiftGen", executable: try targetBuildContext.lookupTool(named: "swiftgen"), arguments: [ "config", "run", "--config", "\(targetBuildContext.packageDir.appending("swiftgen.yml"))" ], environment: [ "PROJECT_DIR": "\(targetBuildContext.packageDir)", "TARGET_NAME": "\(targetBuildContext.targetName)", "DERIVED_SOURCES_DIR": "\(generatedSourcesDir)", ] )

7:21 AM

これswiftgenの出力先はswiftgen.yml に書いてあるだろうけどどうやって動くんだ

SwiftPMが書込み可能な一時ディレクトリを作って、それをswfitgenのオプションとして渡すみたいな話ですよね？たしか。

渡ってなくない？ DERIVED_SOURCES_DIR の仕様はなさそうなんだよな https://github.com/SwiftGen/SwiftGen

SwiftGen/SwiftGen

The Swift code generator for your assets, storyboards, Localizable.strings, … — Get rid of all String-based APIs! - SwiftGen/SwiftGen

無いんですかｗ

今まで使ってて見た覚えないし、リポジトリ検索してもヒットしない

7:29 AM

strings: inputs: Resources/Base.lproj outputs: - templateName: structured-swift5 output: Generated/Strings.swift xcassets: inputs: - Resources/Images.xcassets - Resources/MoreImages.xcassets - Resources/Colors.xcassets outputs: - templateName: swift5 output: Generated/Assets.swift

ザッとドキュメントさらってみたけど出力ファイルパスのベースを指定するようなやつはなさそう

こういうふうにoutput: で指定するんだよね

プラグイン機構向けに機能を頑張って足すのかな

そういうつもりの話ならまあ動くね・・

というか addCommand にworkindDirectoryを指定するパラメータがあればswiftgenに手を入れずに解決できるのでは？

7:37 AM

あー、でも入力ファイルもSRCROOTからの相対でswiftgen.ymlに書かれてるのか…

let package = Package( name: "MyPackage", dependencies: [ .package(url: "https://github.com/SwiftGen/SwiftGen", from: "6.4.0") ] targets: [ .executable( name: "MyLibrary", plugins: [ .plugin(name: "SwiftGenPlugin", package: "SwiftGen") ] ) ] )

MyPackageの依存関係にプラグインの依存が入る？

8:54 AM

だとしたらプラグイン間のライブラリ依存解決が辛そう…

なるほどたしかに。依存ツールは成果物のバイナリにリンクされないから複数バージョンあっても良いはず

CommandInvocationだから

10:28 AM

そもそもシステムインストールが期待されてるよね

10:29 AM

// swift-tools-version: 999.0 import PackageDescription let package = Package( name: "SwiftGen", targets: [ /// Package plugin that tells SwiftPM how to run `swiftgen` based on /// the configuration file. Client targets use this plugin by listing /// it in their `plugins` parameter. This example uses the `prebuild` /// capability, to make `swiftgen` run before each build. /// A different example might use the `builtTool` capability, if the /// names of inputs and outputs could be known ahead of time. .plugin( name: "SwiftGenPlugin", capability: .prebuild(), dependencies: ["SwiftGen"] ), /// Binary target that provides the built SwiftGen executables. .binaryTarget( name: "SwiftGen", url: "https://url/to/the/built/swiftgen-executables.zip", checksum: "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" ), ] )

10:29 AM

いや、ツールバイナリ自体はSwiftPMが固定するのか

10:29 AM

try targetBuildContext.lookupTool(named: "swiftgen"), じゃあこれは結構特殊なlookupなんだな

Windows版Swift、最近のスナップショット (2月18日分から？) で swift build とか swift run が普通に使えるようになってて最高

3

1

Package 内部では target で swiftSettings: [ .define("XXX") ] とすればソース内 #if XXX のようにマクロが使えるようになりますが，依存パッケージに対してマクロを指定することってできますか？ Package A で #if XXX のようなコードを書いておき，それに依存する Package B が dependency の中で A に対して上のように設定したい。（既出だったらすみません） (edited)

確かできないはずなので、やるとしたらswift buildコマンドを叩くタイミングで-Xswiftc -DXXXみたいにして、全てのコンパイルに対して設定することになると思います (edited)

なるほど，了解です

Xcode から直接 Package.swift を開いた場合に（xcodeproj ではなく）、swift flags を設定してビルドしたりテストを回したりってできないですかね？上のようなことをしたかったらコマンドラインから実行するしかないでしょうか？

うーん、ちゃんと把握しているわけじゃないんですが出来なさそうですよね

4:08 AM

generate-xcodeproj にはxcconfigを指定してビルド設定を上書きする機能があります

ふーむ，なるほど．C 感覚でこういうことするのもダメなんですねw dependencies: [ #if USE_A .package(path: "../a/") #endif ],

依存をプラットフォームごとに切り替えるだけなら、このAPIが使えるかもですね https://github.com/apple/swift-package-manager/blob/main/Documentation/PackageDescription.md#target-dependency-condition

https://github.com/omochi/SwiftPM-StringResource-Trial

The Package Manager for the Swift Programming Language - apple/swift-package-manager

4:18 AM

最終的にやりたいことを教えてもらえれば、ズバッと解決する方法が提案できるかもしれないです

三つのパッケージが C > B > A という依存関係になっていて，B が A を使うかどうかを C 側でコントロールできるようにしたい，という感じです． A は外部ライブラリのラッパーのようなもので，標準では含まれない感じにしたいという． (edited)

4:22 AM

C をビルドするときに -Xswiftc -DUSE_A と指定すると，B は A も含めてビルドされるし，指定しなければ A を含めずにビルドされる，という感じにしたいです． (edited)

そもそもコンパイル対象にしたくない、というのはかなり難しいですね。

4:27 AM

もしコンパイル&プログラムにリンクされることが許容できるのであれば実行時に環境変数などを元に切り替える機構を作るほうがシンプルだと思います (edited)

なるほどなるほど，了解です．

フルセットCとスリムCのようにターゲットを２種類用意して、というのいいんじゃないかなあ。 (edited)

1

そうですね，B を A に直接依存させず，C 側でターゲットを分けるなりしてコントロールするのがよさそうな気がしました．ありがとうございます

ご相談させて頂いた件ですが，プラットフォームの条件に加えて（依存パッケージが Obj-C を使うため Linux だとビルドできない），define で ON/OFF を切り替えられる感じにしてみました

色々とアドバイスありがとうございました

https://github.com/taketo1024/swm-homology/blob/83c1a71dedab5183c69ddb45d5985a9e1359d8c2/Package.swift#L31-L42

taketo1024/swm-homology

Contribute to taketo1024/swm-homology development by creating an account on GitHub.

将来的に依存元から依存先に対して define できるようになるといいなぁ

ビルドフラグでのパッケージ内容の変化って、ソースツリーに対するパラメータとして捉えられますけど、ネームスペースもないから導入するライブラリ間でコンフリクトしうるしし、どういうパラメータがあるのかが暗黙的だし、手法として綺麗じゃないのでその辺のサポートの強化は進まない気がします。

12:46 PM

.condition(platforms: []) は昔と違って今はできるようになっているので、なんかパッケージが自身のビルドに影響を与えるパラメータを宣言するような仕組みとセットでの導入ならありえるかも？ただ議論してるのは見たことないので言わないと始まらない状況かも。

Cargoのfeature flag的な仕組みですよね (edited)

そういう仕組みを備えたパッケージマネージャ（ビルドシステム？）があるんですね。

12:48 PM

CargoはRustでしたっけ？

そうですそうです。CargoはRustのSwiftPM的立ち位置です

[features] # Defines a feature named `webp` that does not enable any other features. webp = [] なるほど？

ほう

// This conditionally includes a module which implements WEBP support. #[cfg(feature = "webp")] pub mod webp; なるほど。

で、パッケージの依存をfeatureによって切り替える機構と、言語のソースコードレベルでifdefみたいな機構も提供しています (edited)

Kishikawa Katsumi

// This conditionally includes a module which implements WEBP support. #[cfg(feature = "webp")] pub mod webp; なるほど。

これがソースコードレベルでのfeature分岐です (edited)

これはいいんじゃない。

Rustは非同期ランタイムがいくつかあるので、featureによって使うランタイムを切り替えたりするのに使われることが多いですね

ライブラリ作る人は大変になるか。。。？

12:53 PM

別にFeatureを分離しなければ難しくはならないか。機能を使う人が大変になるだけか？

僕はまだ基本的にライブラリを使う側でしかfeatureを使ったことないですが、featureの定義がコンフリクトして辛いみたいなことは体験したことないです。単にラッキーなのかもしれないけど (edited)

Rustのそのfeatureはグローバルなのか。

機能を使う人っていうのはFeature機能を使ったライブラリを書く人は大変そう、って意味でした。

12:58 PM

ライブラリを使う側もまあ多少大変さはありそうだけどだいたい作る人がうまいことデフォルトを用意してそう。

Rustから学ぶことは多いなぁ

フラグの利用はPackage.swiftのレベルにとどめておいて、コード側は canImport で制御できるとトリッキーな利用が減らせて良さそう

omochi/SwiftPM-StringResource-Trial

Contribute to omochi/SwiftPM-StringResource-Trial development by creating an account on GitHub.

3:29 AM

SwiftPMでのローカライズしたリソースの利用を検証したんですが、 swift test 経由と swift run 経由で、選択される言語が変わってしまうのですが、何か知ってる人居ませんか

https://developer.apple.com/documentation/Xcode/documenting-a-swift-framework-or-package

10:50 PM

jazzyが切れる

これまだ来てない？ https://twitter.com/yutailang0119/status/1402157945287188508

Yutaro Muta (@yutailang0119)

Swift PackageのPlatformに、まだbeta OS含まれてない？ https://t.co/wp2iMUsGRV

.macOS("12.0") でなんとか

文字列指定できたんですね https://developer.apple.com/documentation/swift_packages/supportedplatform/3112760-macos?changes=latest_minor

import Foundation print("begin") for (k, v) in ProcessInfo.processInfo.environment { print("\(k)=\(v)") } print("end")

4:00 AM

こういう簡単なコードを書いて

4:01 AM

$ AAAAAAAAAAAAAAAAAA=foo swift run こうやって実行すると、出力に AAAAAAAAAAAAAAAAAA=foo が出てくるんですが

4:01 AM

$ DYLD_PRINT_LIBRARIES=YES swift run これは、やってもだめで、当然、DYLD_PRINT_LIBRARIES の効果も発動しないので困っています

4:01 AM

これはなぜだろう？

4:02 AM

SwiftPMが余計なフィルタ処理をしているのかと思ったのですが

4:02 AM

https://github.com/apple/swift-package-manager/blob/be8d3c3f72c70e6fbaad16e6bc0d8d7fa15e646e/Sources/Commands/SwiftRunTool.swift#L198

https://github.com/apple/swift-tools-support-core/blob/main/Sources/TSCBasic/misc.swift#L37

The Package Manager for the Swift Programming Language - apple/swift-package-manager

4:03 AM

apple/swift-tools-support-core

Contains common infrastructural code for both SwiftPM and llbuild. - apple/swift-tools-support-core

4:03 AM

自分で追った限りでは普通に execve をまっすぐ呼び出しに行っているだけで、そのような特別な処理は見当たりませんでした

あれ、普通に環境変数全部出ますよ

DYLDのダンプも出るようになる？

はい

4:07 AM

$ swift package init --type executable でやってみた？

4:08 AM

この件、例のSwiftSyntaxの話で、 Xcode12.5のlibISSSPを DYLD_LIBRARY_PATH で通そうとしているのだけど、

試したパッケージ

tmp.YU19hpKb.zip

3.23 KB

swift-cliからだとできないという状態で、それを掘り下げてるものです。

まだ格闘してるのか…たいへんそう

xcodeからの実行だといける。

当方SwiftPM 5.4です (edited)

同じく。　↑のファイルでやっても同じ結果だ。

4:10 AM

OS?

というか、swift-run自体のローダのログも出てないので、swift-runの問題では無さそう

4:11 AM

11.4 (20F71)

4:12 AM

実行ファイルを直接叩くといけるんですよね。

4:12 AM

swift run 経由のときだけの現象。

なんでだろ～

なんか hardened runtime で DYLD_ 系まとめて無効みたいなやつありませんでしたっけ

4:14 AM

それで消されてるのかも

https://developer.apple.com/documentation/security/hardened_runtime

https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_allow-dyld-environment-variables

なるほど、swift-runの実行バイナリにそういうセキュリティ機構が適用されてるのか

ほうほうほう　これっぽい匂いがする

一回でも hardened runtime なプロセスが挟まるとそこで DYLD_ 系が消えちゃうっぽい

$ xcrun -find swift-run /Applications/Xcode12.5.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift-run

4:19 AM

ポン置きのCLIツールのentitlementsってどうなってるんだ？

$ DYLD_PRINT_LIBRARIES=YES /usr/local/bin/bash dyld[....]: ......... $ /usr/local/bin/bash dyld[....]: ......... $ /bin/bash The default interactive shell is now zsh. To update your account to use zsh, please run `chsh -s /bin/zsh`. For more details, please visit https://support.apple.com/kb/HT208050. $ /usr/local/bin/bash

Mach-Oに埋まってるはず

たぶん which swift が /usr/bin/swift なのでそこで消されてそう

ほほー DYLD_PRINT_LIBRARIES=YES xcrun swift run これだと大丈夫だ

逆にxcrun はいいのかw

/usr/bin/swift を経由しないから！？

ええｗ

なるほどｗ

ポリシーが迷走しているｗ

Yuta Saito

Mach-Oに埋まってるはず

読み出す方法をググってます

4:22 AM

なんかツールを自作する方法ばっか出てくるんだがもしかして無いのか

プログラマブルに取り出す方法はわかるけど、ツールでエイっとやる方法はしらない

4:23 AM

こういうパーサを作ったことがあるw https://github.com/kateinoigakukun/MachOParser

ldid(適当な署名付けるくん)にentitlements表示する機能もあったはず。適当にやると署名上書きしちゃうので気をつけないといけないけど (edited)

草　普通逆や

あとはまあバイナリエディタで開いて適当にXML っぽい文字列検索するとか

00021520 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 22 31 |<?xml version="1| 00021530 2e 30 22 20 65 6e 63 6f 64 69 6e 67 3d 22 55 54 |.0" encoding="UT| 00021540 46 2d 38 22 3f 3e 0a 3c 21 44 4f 43 54 59 50 45 |F-8"?>.<!DOCTYPE| 00021550 20 70 6c 69 73 74 20 50 55 42 4c 49 43 20 22 2d | plist PUBLIC "-| 00021560 2f 2f 41 70 70 6c 65 2f 2f 44 54 44 20 50 4c 49 |//Apple//DTD PLI| 00021570 53 54 20 31 2e 30 2f 2f 45 4e 22 20 22 68 74 74 |ST 1.0//EN" "htt| 00021580 70 3a 2f 2f 77 77 77 2e 61 70 70 6c 65 2e 63 6f |p://www.apple.co| 00021590 6d 2f 44 54 44 73 2f 50 72 6f 70 65 72 74 79 4c |m/DTDs/PropertyL| 000215a0 69 73 74 2d 31 2e 30 2e 64 74 64 22 3e 0a 3c 70 |ist-1.0.dtd">.<p| 000215b0 6c 69 73 74 20 76 65 72 73 69 6f 6e 3d 22 31 2e |list version="1.| 000215c0 30 22 3e 0a 3c 64 69 63 74 3e 0a 09 3c 6b 65 79 |0">.<dict>..<key| 000215d0 3e 63 64 68 61 73 68 65 73 3c 2f 6b 65 79 3e 0a |>cdhashes</key>.| 000215e0 09 3c 61 72 72 61 79 3e 0a 09 09 3c 64 61 74 61 |.<array>...<data| 000215f0 3e 0a 09 09 43 39 55 4b 59 6e 61 68 38 57 6d 47 |>...C9UKYnah8WmG| 00021600 68 50 42 4f 6e 38 31 52 6d 54 44 69 39 48 30 3d |hPBOn81RmTDi9H0=| 00021610 0a 09 09 3c 2f 64 61 74 61 3e 0a 09 3c 2f 61 72 |...</data>..</ar| 00021620 72 61 79 3e 0a 3c 2f 64 69 63 74 3e 0a 3c 2f 70 |ray>.</dict>.</p| 00021630 6c 69 73 74 3e 0a 30 0d 06 09 2a 86 48 86 f7 0d |list>.0...*.H...|

$ strings /usr/bin/swift llvm-gcc clang llvm-g++ clang++

objdumpでLC_CODE_SIGNATUREのオフセットがわかるのでそれを頼りに見つけた

4:26 AM

でもなんかシリアライズされたplistっぽいな…

たぶん SIP で縛られてるところは勝手に hardened runtime 相当になっている?

swift-run　からも見つからないな

rinsuki

たぶん SIP で縛られてるところは勝手に hardened runtime 相当になっている?

なるほど

4:27 AM

@Yuta Saito SIP切ってる？

あ、切れてそう

1

なんかそうっぽいなあ

DYLD_PRINT_LIBRARIES=YES "$(xcrun -f swift)" とかしてやるとよさそう

もうちょっときれいな方法ないかしら

あるいは /usr/bin/swift とか /usr/bin/xcrun を適当なSIPが効かないPATHのどこかにコピーしてやるとか (それもそれで…)

うーむ。まあパスの設定自体大変だし、xcrun経由の実行をスクリプトに包むか・・・ (edited)

4:31 AM

xcrun経由だといけるのも、意図的な状態とは思えないので、なんかある日だめになりそうで嫌だなあ

ちなみにxcrun経由でいけてないですね

4:32 AM

(xcrun swift test はだめだった)

うちも xcrun swift だとダメですね

ズコー

rinsuki

DYLD_PRINT_LIBRARIES=YES "$(xcrun -f swift)" とかしてやるとよさそう

xcrunにパスを持ってこさせてそれを直起動すれば通るというやつ

あ、スクリプトなら、バイナリ直たたきすればいいので、swift-runじゃなくて

4:33 AM

$ swift build $ DYLD_LIBRARY_PATH=... ./build/debug/codegen でいいですね。

4:33 AM

$ swift test の生実行はどうやるんだ？

4:33 AM

$ xctest test.bundle だっけ

DYLD_PRINT_LIBRARIES=YES "$(xcrun -f swift)" test とかでいけないかな

xcrun xctest .build/debug/ExamplePackageTests.xctest

4:35 AM

あ、xcrunがだめなのか

DYLD_LIBRARY_PATH=/Applications/Xcode_12.5.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx xcrun xctest .build/debug/SwiftTypeReaderPackageTests.xctest

これはだめだった

xcrun越しの実行じゃなくて、xcrun -f でとってきたパスに対する実行なのね。

そうですそうです

@Iceman これだとどうだろう？

DYLD_LIBRARY_PATH=/Applications/Xcode_12.5.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx $(xcrun -f xctest) ./build/debug/SwiftTypeReaderPackageTests.xctest

4:39 AM

みなさんのおかげでかなり見えてきました、ありがとうございます。これはかなり難しいやつだった。

❯ DYLD_LIBRARY_PATH=/Applications/Xcode_12.5.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx /Applications/Xcode_13_beta.app/Contents/Developer/usr/bin/xctest -XCTest .build/debug/SwiftTypeReaderPackageTests.xctest/2021-06-11 13:40:03.625 xctest[27034:1392524] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[__NSSetM addObject:]: object cannot be nil' *** First throw call stack: ( 0 CoreFoundation 0x00007fff205b287b __exceptionPreprocess + 242 1 libobjc.A.dylib 0x00007fff202ead92 objc_exception_throw + 48 2 CoreFoundation 0x00007fff206682ea _CFThrowFormattedException + 202 3 CoreFoundation 0x00007fff2066f993 -[__NSSetM addObject:].cold.2 + 0 4 CoreFoundation 0x00007fff205168de -[__NSSetM addObject:] + 720 5 XCTest 0x0000000109375314 -[XCTTestIdentifierSetBuilder addTestIdentifier:] + 64 6 xctest 0x0000000109174a84 main + 1963 7 libdyld.dylib 0x00007fff2045af5d start + 1 8 ??? 0x0000000000000003 0x0 + 3 ) libc++abi: terminating with uncaught exception of type NSException [1] 27034 abort DYLD_LIBRARY_PATH= -XCTest .build/debug/SwiftTypeReaderPackageTests.xctest/

4:40 AM

余計なものまで入れ替えてしまってるのでクラッシュしてしまう？

$(xcrun -f xctest) .build/debug/SwiftTypeReaderPackageTests.xctest/ Test Suite 'All tests' started at 2021-06-11 13:40:58.856 Test Suite 'SwiftTypeReaderPackageTests.xctest' started at 2021-06-11 13:40:58.857 Test Suite 'SwiftTypeReaderTests' started at 2021-06-11 13:40:58.857 Test Case '-[SwiftTypeReaderTests.SwiftTypeReaderTests testEnum]' started. Segmentation fault: 11

-XCTestいらなそう

そもそも普通に落ちるわ　俺も

-XCTest はずしたらとおった

あれか、swift-testからコマンド抜いてくるか

-vで丸見え

そもそもswift testが落ちるのでこっちは別の問題がありそう Icemanいけたならとりあえず良かった

4:44 AM

しかしこれは常人には使い物にならんな

4:45 AM

やはりlibISSPも配布せねばならぬ

4:45 AM

swift package clean でtest通った　追いついた (edited)

peripheryはlibISSP同梱して配布してるので参考になるかも https://github.com/peripheryapp/periphery

先人も同じ結論に至っていたのか

4:47 AM

#if swift(>=5.5) dependencies.append( .package( name: "SwiftSyntax", url: "https://github.com/apple/swift-syntax", .branch("release/5.5-05142021") ) ) #elseif swift(>=5.4) dependencies.append( .package( name: "SwiftSyntax", url: "https://github.com/apple/swift-syntax", .exact("0.50400.0") ) ) #elseif swift(>=5.3) dependencies.append( .package( name: "SwiftSyntax", url: "https://github.com/apple/swift-syntax", .exact("0.50300.0") ) ) #else fatalError("This version of Periphery does not support Swift <= 5.2.") #endif

4:47 AM

あ！こんなところにXcode beta対応版SwiftSyntaxのブランチが！

草

https://github.com/peripheryapp/periphery/pull/337/files

Add support for Swift 5.5 by ileitch · Pull Request #337 · peripher...

4:47 AM

3日前だ　やるね

やっとるなw

ISSP配布してるのどこらへん？

4:48 AM

とくにやってないように見える

たしかMakefileに起点があったはず

4:49 AM

これだ https://github.com/peripheryapp/periphery/blob/master/scripts/release

peripheryapp/periphery

A tool to identify unused code in Swift projects. Contribute to peripheryapp/periphery development by creating an account on GitHub.

cp "$(xcode-select -p)/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx/lib_InternalSwiftSyntaxParser.dylib" .release

4:50 AM

そのまんまコピーしてぽん置きやな

install_name_tool は使ってないな実行ファイルの隣に置いてOSが自然に見つけるパターンか

ここで使ってる？ https://github.com/peripheryapp/periphery/blob/master/Makefile#L6

peripheryapp/periphery

A tool to identify unused code in Swift projects. Contribute to peripheryapp/periphery development by creating an account on GitHub.

あ。ほんとだ。

loader_pathの横にあるときでも明示的にやらないとだめっぽい

知見だ

呼び出し側のrpathに追加してるのねなるほど (edited)

4:52 AM

また夜やってみます、periphery参考になりそうありがとう

今週はmacOSの知見がよく集まりますねw

Xcode13betaが出たことでいろいろ起きてるｗ

SwiftPMでBundle.moduleを使っているライブラリをxcodebuild archiveすると.oファイルが作られるのですが、これってBundleもoファイルの中に詰め込まれているんですかね…？

oファイルはオブジェクトファイルだから無理じゃないか？？

ですよね。なんかxcarchiveの中にbundleが入っていないんですけど何がおかしいんだろう…

xcodebuild archiveがresource付きのswiftpm packageに対応していないんじゃないか　しらんけど

それありそうですね別でbundleだけ作ってコピーするかxcframework用にxcodeproj作る感じになりそう

Beta 3でハマったので共有 https://twitter.com/d_date/status/1415521747491713030?s=20

Date (@d_date)

Beta 3からSwiftPMではApp Extensionで使えないAPIについてはエラーがでるようになったので、App Extensionで利用できないものには @ available(iOSApplicationExtension, unavailable) をつけてApp Extensionでは利用できないことを明示する必要がある https://t.co/cPk9GBZkYE

1

3

@d_date spm運用でプレビューに問題あるって話やけど、解法がわかったので共有しておくね問題が発生するのは2つ。 X1. Previewのコードが直接含まれるlibraryをtype: .staticでproductに宣言している場合 X2. Bundle.moduleを利用している場合それぞれ、 A1. AppやExtensionのためにproductに宣言するためのライブラリを1個宣言して作っておく。あわせて、ComponentのレイヤはPreviewsとしてまとめてtype: .dynamicでproductに宣言しておく。

 // 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を書く。辛いけど仕方ない。 (edited)

SwiftUI Previewer crashes while in swift package that depends on an...

On Xcode 12.1, SwiftUI Previewer crashes when it references another swift package it depends on and that swift package uses Bundle.module. Basic code snippet that crashes: import SwiftUI import Theme // Import package that uses Bundle.module /// This view will crash the previewer struct ThisViewCrashesPreview: View { var body: some View {...

X1は事象に遭遇してないのでよくわかんないけど、X2はXcode12.4でも確認していて、12.5で治っている。しかし、12.5以降でも例えばxibをPackage.target.resourcesに.processで書くとBundle.moduleで読み取れないので、これはPackage.swiftに書かないが正解。扱いのわかるファイル形式は特に宣言しなくても勝手に扱ってくれる (see WWDC)

3:57 PM

@tarunon

Bundle.module、平時は動くけどPreviewだと作られないという罠があるねんな

3:58 PM

それ自体はXcode13でも起きる

↑はPreviewの話

むむ

クラッシュログがこういうのだよね？(上のForumから抜いてきた) Application Specific Information: Fatal error: unable to find bundle named Theme_Theme: file Theme/resource_bundle_accessor.swift, line 27 (edited)

そうそう

宣言削ってうまくいきましたどっかのタイミングで警告出てたから宣言いるものと思い込んでたわ、ありがと @d_date

1

そういえばこれ、上手く行ったと思ってたら結局間違ってBundle.main参照してたというオチでした。Bumdle.moduleは結局Previewで壊れるので回避する運用にしちゃった fyi @d_date

1

swift packageのサブコマンド、swift 5.5とmainで色々diffあって楽しい https://github.com/apple/swift-package-manager/blob/main/Sources/Commands/SwiftPackageTool.swift

swift-package-manager/SwiftPackageTool.swift at main · apple/swift-...

The Package Manager for the Swift Programming Language - swift-package-manager/SwiftPackageTool.swift at main · apple/swift-package-manager

https://github.com/apple/swift-package-manager/blob/main/CHANGELOG.md#swift-56

Soft deprecate .package(name:, url:) dependency syntax in favour of .package(url:), given that an explicit name attribute is no longer needed for target depedendencies lookup.

これもしかしてPackage.swiftの難しいところがちょっと改善されるやつかな？

swift-package-manager/CHANGELOG.md at main · apple/swift-package-ma...

The Package Manager for the Swift Programming Language - swift-package-manager/CHANGELOG.md at main · apple/swift-package-manager

お、product nameをあわせないといけないやつが楽になるのかな

SwiftPMはアップデートのタイミングがSwiftのアップデートになってしまうんだなあ。

たしかに。

未だ5.3のtoolchain使ってます

https://forums.swift.org/t/pre-pitch-swiftpm-manifest-based-on-result-builders/53457/24

[Pre-pitch] SwiftPM Manifest based on Result Builders

By definition, any and all features that would add a parameter to said "giant-initializer"s would be difficult to add without further increasing the complexity of the existing APIs. To your point about forcing the community to adapt: that's just not true. Any package marking its manifest with an older version should keep working, just like they...

4:26 AM

Package.swift を Result Builder で書けるようにする話が出てる

kitasukeさんが欲しい！やっぱいらん！ってやってたヤツかな

そう

うごけばいいかな…

現状の仕様の問題点が複数挙げられているんだけどその一つで巨大なinitになっているので、型推論の負担が大きくて、ワンミスで全体が型エラーになって、書きづらいというユーザビリティがあげられていた (edited)

メリットあるやろか

あー、なるほど

分散したいのか

これはたしかにそうだなと思った。

4:28 AM

ちょっとミスると全滅するんだよね

どうせビルダーパターンやるならresultbuilerの方がカッコええやろwってことね

もう一つは、分岐がある場合に大きく書き方が変わっちゃう、というのがあった

でもフィールドに . 書くとそこに書ける候補がズラッと補完にでる体験は捨てがたい

1

1

それは分岐を抑制する良い仕様だったのでは？とも思ったが。

分岐かあ

4:29 AM

たしかに

分岐抑制結局

DSLむずい

分岐しないでくれ

appleのツールチェーンも分岐祭だし

なんでもできるようにすると大変

仕組みで縛ってもムリってことに気が付いたんじゃないか (edited)

まあ他にもいろいろ書かれてるんだけど英語なのもあってよくわからない点もあった。

4:30 AM

1. The manifest defines 2 publicly available build artifacts, an executable named MyExecutable and a library named MyLibrary. To define these artifacts, the manifest requires definition of two abstractions: a Target and a Product, having the Target representing a source module and the Product representing a public build artifact. Worth noting that in many cases, each Product points to exactly one Target.

4:30 AM

これとかは、現状の面倒な点ではあるけど、ResultBuilderにすべき理由にはなってないように思う。

そうだね

そうだと思う

RBは結構強烈な副作用を伴う機能だから

4:31 AM

実はただのクロージャ式を用いたビルダーパターンで十分でした、みたいなのは普通にある

強烈な副作用?

副作用は不適切な語だな

4:32 AM

1ライナー強制、複数返り値の定義など

4:33 AM

本来やりたかった問題解決を大幅に超える機能が齎される

1

読めない漢字が

問題解決と引き換えに、大量の制約が加わるんですよね

4:33 AM

もたらす

1

var package = Package(..) package.addProduct(name: "Foo")

4:33 AM

Swiftのstructは本質的にbuilder patternだから

4:33 AM

現状のPackage型に、便利メソッドを追加してやれば

4:34 AM

「二重に定義するのがめんどくさいよね」系は解決できる気がする

4:34 AM

ていうかgiant initializer問題もそれで解決する

書いてみて良い気がするな

4:35 AM

幾つか反論は思い付くけど、理にかなった主張だと思います

スレがすでに長いんよｗ

1

4:35 AM

今本業が忙しくて、スレ読んで主張まとめて英作文する暇が無い。

4:35 AM

まあまだ pre-pitch だから

4:36 AM

余裕があったら書いてみよう

4:37 AM

本業忙しい問題、Xcode13のバグの報告する宿題がめっちゃ溜まってるのもあったんだった。

1

以前こちらで議論されていた .module 指定でPreviewできない件、自分もハマったのでまとめました。特にココでの議論から進展はないのですが、実は他の解決方法とか新情報がありましたら教えていただけると嬉しいです

https://fromatom.hatenablog.com/entry/2022/01/03/180148

FromAtom

SwiftPMでAssetsを含んだtargetを別のtargetで呼んでSwiftUI Previewするとクラッシュする。 - 文...

わけわからんタイトルだけど、そのままなので仕方ない。環境 Xcode: 13.2.1 Swift: 5.5.2 背景 iOSDC 2021でこの発表をみて、SwiftPM中心のプロジェクト構成にしようとする人は多いだろう。 fortee.jp 自分もその一人で、その中ではまった問題。 SwiftPM中心のプロジェクト構成にするとMulti Module化がしやすくなるので、機能ごとや画面ごと（プロジェクトの設計によるが）にModule（Package.swiftでいうTargets）を分割していく。そうすると自然と .xcassets も分割されていく。上記発表ではBundleに Bund…

3

.intentdefinition のように Xcode が自動生成するファイル（ FooIntent.swift ）があるものを、うまく Swift Package に閉じ込める方法をご存じの方がいたら教えてほしいです

（初心者向けの質問ではないので beginner-help ではなくこちらに投稿しました、不適切でしたらご指摘ください）

https://discord.com/channels/291054398077927425/380329942505750529/937579155174875147

swiftpmで特定の孫依存パッケージとかだけ、差し込みで自前の改造バージョンにする方法ってありますか？

使ったことないけど、この辺り？ https://github.com/apple/swift-evolution/blob/main/proposals/0219-package-manager-dependency-mirroring.md

swift-evolution/0219-package-manager-dependency-mirroring.md at mai...

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swift-evolution/0219-package-manager-dependency-mirroring.md at main · apple/swift-evolution

ありがとうございます、みてみます

https://github.com/apple/swift-package-manager/blob/main/Sources/PackageDescription/PackageDependency.swift#L414-L415

swift-package-manager/PackageDependency.swift at main · apple/swift...

The Package Manager for the Swift Programming Language - swift-package-manager/PackageDependency.swift at main · apple/swift-package-manager

3:41 AM

swiftpmの新しいAPIの、enumじゃなくてラベルで指定するスタイルのやつなんだけど

3:41 AM

exact: の場合のコメントが

3:42 AM

 /// It allows you to specify the minimum version you require, allows updates that include bug fixes /// and backward-compatible feature updates, but requires you to explicitly update to a new major version of the dependency.

↑マイナーバージョンは固定しないように見えるんだけど、コメントが間違ってるのか、それともexactがこう変わった（元から？）んだろうか？ (edited)

3:42 AM

関連して、今まで使われていたやつがdeprecatedになっていて

@available(_PackageDescription, deprecated: 5.6, message: "use specific requirement APIs instead (e.g. use 'branch:' instead of '.branch')") public static func package( url: String, _ requirement: Package.Dependency.Requirement )

(edited)

3:44 AM

.upToNextMajor → from: (前からあった) .branch → branch: .revision → revision: の対応があるんだけど、 .upToNextMinor の対応が存在しなくて、コメントからするとそれが exact: に見えるで .exact の対応してそうな exact: は消えた？

3:44 AM

@d_date この前の発表内容に近い話だけど、何か知ってますか

upToNextMinor達はRangeのextensionに移ったらしい https://github.com/apple/swift-package-manager/commit/8dd0202d01f0d644a9d0a12fb039892d8828c240

3:54 AM

ざっとdiff見る限りexactの動きは変わってなさそうだけど、確かにコメントは変わってますね

むむ、じゃあ .upToNextMinor はドット形式で今後も書けるのか。ただし実はドットがついてる左辺値型が変わるのか。

3:59 AM

exactはコメントだけ壊れちゃったのかな。

かなぁ

メジャーアプデも辞さない .latestStable 的なものも欲しいですが、そこらへん何か議論あったりしますかね

たしかに上限のないRangeって指定できない気がしますね。 majorアップデートは互換性を壊すので、壊れて良いならブランチmain指定で良い気がしますが

mainが必ずしも毎回リリースされてるとは限らないのと、そもそものモチベーションとしては現状のSwiftPMではメジャーアプデが来た時に、何かbot作ってリリースを見張ってないとそれを知る術がないですよね；なので互換性が壊れるのが天然なメジャーアプデ通知みたいなものだと捉えてます()

6:57 AM

そうするとCIで回してるときに互換性が壊れてビルドが通らなくなるので、それを治すのに必然的に今の .upToNextMajor に直さないといけないので、他のパッケージが全部 .latestStable だったら、「あこの .upTpNextMajor のものはメジャーアプデがあるから移行対応しないとだな」ってすぐわかる

DependaBotがSwiftPMに対応してくれればいいのにな〜と調べたらドラフトPRは出てるんですね https://github.com/dependabot/dependabot-core/pull/3772

Add support for Swift Package Manager by mattt · Pull Request #3772...

Initial work to add Swift support to Dependabot. This is currently a work-in-progress, but I'd welcome any feedback on what we have so far.

実はうちの会社でもそのためのDanger-Swiftプラグイン作ってるところです

swift package コマンド経由ならいくらでもやりようあるんですけど、xcodebuild にはversion requirementsを満たす -resolvePackageDependenciesはあるけどアップデートするコマンドがないので、 renovateがやっているようなPackage.swift側で無理矢理Version requirementsをあげてしまう方法しか取れないのが現状です。

1

https://blog.eidinger.info/xcode-133-supports-spm-binary-dependency-in-private-github-release SwiftPMが.netrcの設定を見てAuthenticationヘッダをつけてくれる機能があるらしい。

Xcode 13.3 supports SPM binary dependency in private GitHub release

Learn to distribute binary frameworks (xcframework) with Swift Package Manager (SPM) even if those binaries require authentication. Netrc to the rescue!

そういえばMapboxのパッケージが活用してたような気がします。 https://docs.mapbox.com/ios/maps/guides/install/

Installation | Maps SDK | iOS

Install the Mapbox Maps SDK for iOS.

本当ですね。しかし分かりやすい手順だ。

Swift 5.6 になってから swift run でコマンドラインツールを走らせたときに SIGINT で止まらなくなって困っていたんですが，意外と Jira でも Forums でも Pull requests でもそれらしい言及がなかったので原因を探って PR を出してみました．困っている人は本当に困っていそうな問題なので共有してみます．理解が間違っているところとかがあればご指摘いただけると嬉しいです． https://github.com/apple/swift-package-manager/pull/4224

Fix SIGINT handling during swift run by kkk669 · Pull Request #42...

Fix SIGINT handling during swift run. Motivation: Since Swift 5.6, Ctrl-C no longer works during swift run. The issue was introduced in #3815. That PR added signal(SIGINT, SIG_IGN) for handling SIG...

3

kebo

Swift 5.6 になってから swift run でコマンドラインツールを走らせたときに SIGINT で止まらなくなって困っていたんですが，意外と Jira でも Forums でも Pull requests でもそれらしい言及がなかったので原因を探って PR を出してみました．困っている人は本当に困っていそうな問題なので共有してみます．理解が間違っているところとかがあればご指摘いただけると嬉しいです． https://github.com/apple/swift-package-manager/pull/4224

↑は無事マージされて，今後の Swift 5.6 のパッチバージョンにも含めるつもりみたいです

8

私の環境だと Xcode 13.3 (Swift 5.6) で以下のエラーが発生するのですが、同じ現象が発生した人はいないでしょうか…？ 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 (edited)

ウホーイ🟢 (@the_uhooi)

このエラーが発生するんだけど、ワイの環境だけ？誰か Xcode 13.3 で試していただけると嬉しいです

https://t.co/54BMg6qpOO

特定のパッケージっていうのは https://github.com/uber/mockolo かな？私の環境だと問題なかったです。わからないけど https://stackoverflow.com/questions/71506588/what-is-swiftpm-spmrepositoryerror-error-5 の回答があってそうです。

GitHub - uber/mockolo: Efficient Mock Generator for Swift

Efficient Mock Generator for Swift. Contribute to uber/mockolo development by creating an account on GitHub.

What is "SwiftPM.SPMRepositoryError error 5"?

I've searched Apple's documentation, open source projects, and Google, and I cannot seem to find any information about SwiftPM.SPMRepositoryError error 5. Heck, I can't even find information about

はい、Mockoloです。ご確認いただきありがとうございます

そしたらやはり私の環境の問題のようですね

ローカルで↑の内容を試してみます。

@uhooi git@でPackage.swift定義してる？ (おはよう)

yutailang0119

@uhooi git@でPackage.swift定義してる？ (おはよう)

git@ってurlに指定する文字列の話かな？？ git@ではなく、こんな感じにしてる↓（これは1.6.3だけど、ローカルで1.7.0にして試してる） https://github.com/uhooi/UhooiPicBook/blob/c7d0bc185c5e74af70d939ea16b29348d800555a/Tools/UhooiPicBookTools/Package.swift

UhooiPicBook/Package.swift at c7d0bc185c5e74af70d939ea16b29348d8005...

Uhooi's character book. Contribute to uhooi/UhooiPicBook development by creating an account on GitHub.

じゃあ、関係ないかな？孫依存、その先とかで影響があるのかもだけど

なるほど、、、

.gitconfig に何かあるかもしれません https://blog.web-apps.tech/github-disabled-git-protocol/

GitHubがgit://を無効にした件

TL;DR GitHubからgitプロトコル(git://github.comで始まるURL)でgit cloneする設定になっている人が居たらSSHプロトコル(git@github.comで始まるURL)を使うように設定変更しましょう wez/weztermという端末エミュレータを知って、使ってみようかと思い、ドキュメントに従ってbrew tapしたときのことでした。次の様なエラーが発生して、tapできません。 $ brew tap wez/wezterm ==> Tapping wez/wezterm Cloning into '/opt/homebrew/Library/Taps/wez/homebrew-wezterm'... fatal: remote error: ...

1

情報ありがとうございます！ gitプロトコルが無効になったのは知りませんでした。ただ私はHTTPSプロトコルを使っているし、.gitconfigにもそのような設定はなかったので関係ないかも…？ https://github.com/uhooi/dotfiles/blob/bdee97a8f048629fb1c9f108ef40837f3f79bbcf/.gitconfig

dotfiles/.gitconfig at bdee97a8f048629fb1c9f108ef40837f3f79bbcf · u...

My dotfiles. Contribute to uhooi/dotfiles development by creating an account on GitHub.

The operation couldn’t be completed. (SwiftPM.SPMRepositoryError error 5.)

これ私の環境でも別のプロジェクトで発生しました。開きっぱなしのプロジェクトが気づいたらこのエラーでビルドできなくなってました。 Stack OverflowやForumの回答を読んでましたがどうも関係なさそうと思って ~/Library/Developer/Xcode/DerivedData ディレクトリを消したら直りました。

1

どうも The operation couldn’t be completed. (SwiftPM.SPMRepositoryError error 5.) はXcode 13.2とか前からのプロジェクトをXcode 13.3で開くと起こるっぽい。だから新しいプロジェクトやCIでは起こらなかったんじゃないか。解決方法はDerived Dataを消したり.buildを消したり。

SwiftPM.SPMRepositroyError って SwiftPM 側のエラー型かと思いきや Xcode の内部的なエラー型なのですね．ということはもしかしたら Xcode 固有の問題かもしれないですね．(もしそうであれば .build が原因になることはないような気が...)

kebo

SwiftPM.SPMRepositroyError って SwiftPM 側のエラー型かと思いきや Xcode の内部的なエラー型なのですね．ということはもしかしたら Xcode 固有の問題かもしれないですね．(もしそうであれば .build が原因になることはないような気が...)

（僕もSwiftPMのリポジトリgrepしましたw）

1

私もそれ (関連しうる他のリポジトリも含めて) で出なかったのと，https://cs.github.com/?scopeName=All+repos&scope=&q=SPMRepositoryError の結果から，Xcode.app の IDESwiftPackageCore.framework が持っている型だろうなと判断しました． (edited)

GitHub Code Search (Preview)

12:33 PM

自分で言っていて根拠が薄い気がしたので...

$ nm -g /Applications/Xcode-13.3.0.app/Contents/PlugIns/IDESwiftPackageCore.framework/Versions/A/Frameworks/SwiftPM.framework/SwiftPM | grep SPMRepositoryError 000000000006f64c T _$s7SwiftPM18SPMRepositoryErrorO010underlyingD010repositoryACSgSo7NSErrorC_So32DVTSourceControlRemoteRepositoryCSgtcfC 00000000005ae108 S _$s7SwiftPM18SPMRepositoryErrorO10Foundation09LocalizedD0AAMc 00000000005ae178 S _$s7SwiftPM18SPMRepositoryErrorO10TSCUtility27DiagnosticLocationProvidingAAMc 00000000006b0ba8 S _$s7SwiftPM18SPMRepositoryErrorO10TSCUtility27DiagnosticLocationProvidingAAWP 000000000006f9e8 T _$s7SwiftPM18SPMRepositoryErrorO11descriptionSSvg 00000000005ae1d8 S _$s7SwiftPM18SPMRepositoryErrorO11descriptionSSvpMV 000000000006f684 T _$s7SwiftPM18SPMRepositoryErrorO16errorDescriptionSSvg 00000000005ae1d8 S _$s7SwiftPM18SPMRepositoryErrorO16errorDescriptionSSvpMV 000000000006f9ec T _$s7SwiftPM18SPMRepositoryErrorO18diagnosticLocation8TSCBasic010DiagnosticF0_pSgvg 00000000005ae1d8 S _$s7SwiftPM18SPMRepositoryErrorO18diagnosticLocation8TSCBasic010DiagnosticF0_pSgvpMV 0000000000073e54 T _$s7SwiftPM18SPMRepositoryErrorOMa 00000000005ae204 S _$s7SwiftPM18SPMRepositoryErrorOMn 00000000006b0c78 S _$s7SwiftPM18SPMRepositoryErrorON 00000000005ae188 S _$s7SwiftPM18SPMRepositoryErrorOs0D0AAMc 00000000005ae150 S _$s7SwiftPM18SPMRepositoryErrorOs23CustomStringConvertibleAAMc

Kishikawa Katsumi

The operation couldn’t be completed. (SwiftPM.SPMRepositoryError error 5.)

これ私の環境でも別のプロジェクトで発生しました。開きっぱなしのプロジェクトが気づいたらこのエラーでビルドできなくなってました。 Stack OverflowやForumの回答を読んでましたがどうも関係なさそうと思って ~/Library/Developer/Xcode/DerivedData ディレクトリを消したら直りました。

遅くなりましたが、私も SSH キーなどは関係ないと思って、 .build フォルダなどを削除して resolve し直したら直りました。

Xcodeももうちょいわかりやすいメッセージ出してほしいですよね。

わかりやすいエラーメッセージって出すのすごい難しいと思うなあ。

4:18 AM

そもそもエラーのコンテキストは局所性が高くて、例えば特定の依存する条件が成立しないないみたいなときに、そのコンテキストは依存のとても深くで起こることがあって、それを最上部のユーザーに見える場所でそのコンテキストを得てかつそのたの操作からわかりやすい（つまり原因を説明する）メッセージを出すってことになるので、大規模なシステムになればなるほど仕組み的に困難だと思う。 (edited)

4:19 AM

多分それは例外が嫌われるのとおなじことなのかなあ。

まあ難しいですよね。今回のは私の環境では再現性あって原因も古いキャッシュの何か、って感じで解決してみればわかりやすかったけど通信が不安定なときにも起こるんだろうし、本当にSSHのキーが壊れてたってときにも起こるんだろうし、発生したところを起点にどういう対処をっていうのは難しい。

4:24 AM

とはいえerror 5って言われても困るというのは困る。

任天堂とかSONYの商品はそういう感じが…

4:26 AM

というか世間一般にでまわってる装置のエラーは大抵エラーコード5みたいな感じ

4:27 AM

多分それが普通で、stacktraceとかcoreとかが得られると思ってる方が間違ってるのかもしれない

そう考えるとコンパイラがめちゃめちゃエラーメッセージ頑張ってるのは文字通り異常にすごいことなのかも。

niw

そもそもエラーのコンテキストは局所性が高くて、例えば特定の依存する条件が成立しないないみたいなときに、そのコンテキストは依存のとても深くで起こることがあって、それを最上部のユーザーに見える場所でそのコンテキストを得てかつそのたの操作からわかりやすい（つまり原因を説明する）メッセージを出すってことになるので、大規模なシステムになればなるほど仕組み的に困難だと思う。 (edited)

理想的には各レイヤーでそれぞれのドメインに適したエラーに包み直して、詳細は Java みたいに cause でチェーンして示すというのがいいんでしょうね。すべてが型付けされていれば、最上位レイヤーで起こり得るエラーが（ cause も含めて）型で洗い出すことが可能になり、そこからユーザーが必要になる粒度に応じてエラーメッセージを提供するみたいな。めっちゃ実装面倒ですが。 Swift の Forums でも、仮に Typed Throws を採用しても、複数のエラー型を列挙できるようにはしないという話がされていて、おそらくその理由は各レイヤーでそれらの粒度に応じてエラーを包み直すのが望ましいからかと。

The operation couldn’t be completed. (SwiftPM.SPMRepositoryError error 5.)

わたしの場合はSOなどに記載の通り、sshのkeyをEdDSA (ed25519) で作り直したら解消しました。 SwiftPM.SPMRepositoryError error 3もでておりおそらくこれがsshアクセスのエラーっぽい。 GitHubへ公開鍵を登録するのと、Xcode -> Account -> GitHubのSSH Keyに生成した鍵の名前に変更するのをお忘れなくという感じでしょうか。

4:40 AM

もちろんDerived Data消したりもして解消しなかったのでSSHを疑いにかかった感じです

難しいっすね

omochimetaru

.upToNextMajor → from: (前からあった) .branch → branch: .revision → revision: の対応があるんだけど、 .upToNextMinor の対応が存在しなくて、コメントからするとそれが exact: に見えるで .exact の対応してそうな exact: は消えた？

結構前の話題で恐縮なのですが、Xcode13.3にアップデートして、 .exact の非推奨コメントに自分も遭遇しました。 Xcode13.3を境に .exact -> exact: になったのですね！（新しい方のドキュメントの概要欄は、未記載の状態のようですが...。）

ドキュメント

旧 static func exact(_ version: Version) -> Package.Dependency.Requirement(deprecated)

新 static func package(url: String, exact version: Version) -> Package.Dependency

miharun

結構前の話題で恐縮なのですが、Xcode13.3にアップデートして、 .exact の非推奨コメントに自分も遭遇しました。 Xcode13.3を境に .exact -> exact: になったのですね！（新しい方のドキュメントの概要欄は、未記載の状態のようですが...。）

ドキュメント

旧 static func exact(_ version: Version) -> Package.Dependency.Requirement(deprecated)

新 static func package(url: String, exact version: Version) -> Package.Dependency

MontreyにできてなくてXcode13.3にアップグレードできてないんですが、 exact: のコメントの文章はおかしいままですか？ドキュメントには出力されてないんですねw (edited)

まだおかしいままっぽい https://github.com/apple/swift-package-manager/blob/75ae899c2e24aa4827edbed43a331ce06b7ec505/Sources/PackageDescription/PackageDependency.swift#L416-L420

11:13 AM

後で報告しておこう

1

Yuta Saito

まだおかしいままっぽい https://github.com/apple/swift-package-manager/blob/75ae899c2e24aa4827edbed43a331ce06b7ec505/Sources/PackageDescription/PackageDependency.swift#L416-L420

ｗｗ

omochimetaru

ｗｗ

w 元のスレッドは exact: のコメントが間違ってる話だったのですね！ちょっとズレた話題してしまいました

miharun

w 元のスレッドは exact: のコメントが間違ってる話だったのですね！ちょっとズレた話題してしまいました

元の話題は従来の .upToNextMinor はどうすればいいんだろう、という疑問で、コメントの間違いもあったのでさらに疑問が深まってしまったというものでした。

1

Yuta Saito

まだおかしいままっぽい https://github.com/apple/swift-package-manager/blob/75ae899c2e24aa4827edbed43a331ce06b7ec505/Sources/PackageDescription/PackageDependency.swift#L416-L420

:exact だけでなく、 :from のコメントも同じくおかしいぽいです。おんなじコピペコメントでした。

1

結論としては .exact は exact: に変わるけど、 .upToNextMinor はそのまま使える。

12:14 PM

この exact: とかのAPI変更ってプロポーザルあるんだっけ @d_date 知ってる？

miharun

:exact だけでなく、 :from のコメントも同じくおかしいぽいです。おんなじコピペコメントでした。

あれ、fromもおかしいですか？ from: のやつを exact: に間違ってコピペしちゃったんだと思ってました

1

Yuta Saito

あれ、fromもおかしいですか？ from: のやつを exact: に間違ってコピペしちゃったんだと思ってました

！すみません、その通りです。私の誤解でした！

1

omochimetaru

結論としては .exact は exact: に変わるけど、 .upToNextMinor はそのまま使える。

むむ、じゃあ .upToNextMinor はドット形式で今後も書けるのか。ただし実はドットがついてる左辺値型が変わるのか。

と、以前 omochimetaru さんがコメントしているようになるのだと理解してます

現状の依存関係のバージョンの書き方、まとめてみました↓ 【SwiftPM】依存関係のバージョンの書き方 https://qiita.com/m_rn/items/ef14be6e66d278830e7e

2

omochimetaru

この exact: とかのAPI変更ってプロポーザルあるんだっけ @d_date 知ってる？

プロポーザルはないけどPRはこれ https://github.com/apple/swift-package-manager/pull/3641

deprecate name attribute on package dependencies by tomerd · Pull R...

motivation: follow-on work to the change in 5.5 that allows users to not specify a name on the dependency, this soft-deprecates the ability to do so changes: emit a deprecation warning when using ...

d_date

プロポーザルはないけどPRはこれ https://github.com/apple/swift-package-manager/pull/3641

ありがとう

.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

mobile-app-trends/2021_4q.md at main · uhooi/mobile-app-trends

モバイルアプリ開発のトレンドを3ヶ月ごとに紹介します。. Contribute to uhooi/mobile-app-trends development by creating an account on GitHub.

11:51 AM

（スレを完全には追えていないので、見当外れでしたらすみません）

uhooi

.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 と解釈される、という事です。

swift-package-manager/PackageRequirement.swift at e25a590dc455baa43...

The Package Manager for the Swift Programming Language - swift-package-manager/PackageRequirement.swift at e25a590dc455baa430f2ec97eacc30257c172be2 · apple/swift-package-manager

2

omochimetaru

.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

Xcode の Swift Playgrounds App プロジェクトや Swift Playgrounds の App Project で GUI から Up To Next Minor Version でパッケージを追加したときに Package.swift に自動生成されるのは "1.0.0"..<"1.1.0" だったので，少なくとも Apple 社内にはこっちを推したい派閥がいるのかなと思ってました． 2nd review の時もそういう意見があったり． https://forums.swift.org/t/se-0292-2nd-review-package-registry-service/46917/31 (edited)

SE-0292 (2nd review): Package Registry Service

Package identity Hyphens may not occur at the beginning or end, nor consecutively within a scope. Are there some older accounts without these conditions? For example, https://github.com/lorem--ipsum has consecutive hyphens. A valid package name matches the following regular expression pattern: \A\p{XID_Start}\p{XID_Continue}{0,127}\z Ca...

1

個人的には "1.0.0"..<"1.1.0" は冗長なので微妙だと思うんですよね～

範囲ベタ書きだとミスりそうだし、可読性もちょっと悪いので、自分も微妙だと思います、、

大抵の場合 url: from: "x.y.z" で済むのでこのへんこだわりないのだけど、みんな.upToNextMajorとか書いてるのかな

確かに、基本は from しか使わないなぁ CLI ツールでバージョンを固定したいときに exact を使うくらい

1

executable だと Package.resolved で固定されているので from で問題ないことが多いですが，library の場合だと勝手に API に互換性がないバージョンを使おうとしてビルドできなくなったら嫌なので，自分の場合はマイナーバージョンまで固定してますね．semver 的にはメジャーバージョンが上がれば上がったら API に破壊的な変更が入っているのは明らかですが，マイナーバージョンも勝手に上がっちゃうと有用な新機能を見逃したりするので上げる時は手動で上げたい気持があります．パッチバージョンはバグ修正等なので許容するという感じで． (edited)

人間がやるsemverは信用してないから、どうせ全部見ることになるかな

僕は小・中くらいのライブラリは from: ですが大きいライブラリは .upToNextMinor で指定してますね。マイナーバージョンでも壊してしまう事はたまにあるだろうという前提で、それが起こったときに大きいライブラリだと状況の解析が大変だから。

kebo

↑は無事マージされて，今後の Swift 5.6 のパッチバージョンにも含めるつもりみたいです

swift run が Ctrl-C で止まらない問題の修正，5.6.1 リリースにちゃんと含まれてました．しかし Xcode 13.3.1 に同梱されているのはまだ 5.6.0... https://www.swift.org/download/

https://developer.apple.com/documentation/packagedescription/package/init(name:defaultlocalization:platforms:pkgconfig:providers:products:dependencies:targets:swiftlanguageversions:clanguagestandard:cxxlanguagestandard:)

Swift is a general-purpose programming language built using a modern approach to safety, performance, and software design patterns.

13.3.1はrelease noteに載ってるのだけしか変わって無さそう

Identifiable は Swift 5.1 からだけど、これを利用するライブラリを Swift 5.1 以降のみに提供したいとして、 Package.swift にどのように記述するのが良いでしょうか？ platforms で記述すると全プラットフォームサポートするの大変だし（ Linux や Windows は指定できない？）、 swiftLanguageVersions でも .v5 とかの単位でしか指定できない？

// swift-tools-version:5.1 だとダメですか？

1

2:17 AM

5.1はだいぶ中途半端だと思うので5.5かいっそ5.6でいいと思いますけど。

それだと5.1コンパイラを5.0モードにした時にはエラーになりそうだけど概ね問題なさそう

// swift-tools-version: 5.6 ↑でも Identifiable を使おうとするとビルドエラーになりますね。ツールのバージョンとサポートされる言語のバージョンは別かと。 (edited)

Apple系だけplaftorms指定するので十分じゃないですすか？

koher

// swift-tools-version: 5.6 ↑でも Identifiable を使おうとするとビルドエラーになりますね。ツールのバージョンとサポートされる言語のバージョンは別かと。 (edited)

ソースコード側で #if swift は使いたくない？

Iceman

Apple系だけplaftorms指定するので十分じゃないですすか？

Linux 等の場合は単にサポートされてないバージョンの Swift でビルドしようとしたときのみエラーになるということですか？

koher

Linux 等の場合は単にサポートされてないバージョンの Swift でビルドしようとしたときのみエラーになるということですか？

そうなります。

omochimetaru

ソースコード側で #if swift は使いたくない？

Identifiable のためのライブラリなので、何もなくなってしまう。 (edited)

final public var swiftLanguageVersions: [PackageDescription.SwiftVersion]? public enum SwiftVersion { /// A user-defined value for the Swift version. /// /// The value is passed as-is to the Swift compiler's `-swift-version` flag. case version(String) }

(edited)

2:36 AM

swiftLanguageVersions: [.version("5.1")] って書けないのかな

Iceman

そうなります。

↓これだと Linux からビルドできないと思ってたけどできるんですっけ？ platforms: [.macOS(.v10_15), .iOS(.v13), .tvOS(.v13), .watchOS(.v6)],

できます。

koher

↓これだと Linux からビルドできないと思ってたけどできるんですっけ？ platforms: [.macOS(.v10_15), .iOS(.v13), .tvOS(.v13), .watchOS(.v6)],

言及がないプラットフォームは許可される

platformsの指定は指定しなかったらデフォルト値

koher

↓これだと Linux からビルドできないと思ってたけどできるんですっけ？ platforms: [.macOS(.v10_15), .iOS(.v13), .tvOS(.v13), .watchOS(.v6)],

できますよ。普段指定してないです

omochimetaru

final public var swiftLanguageVersions: [PackageDescription.SwiftVersion]? public enum SwiftVersion { /// A user-defined value for the Swift version. /// /// The value is passed as-is to the Swift compiler's `-swift-version` flag. case version(String) }

(edited)

それも試したけどだめだった。

koher

それも試したけどだめだった。

これはビルドする内側に使うものなのか。外側から見た互換性の宣言ではないのか。

言及がないプラットフォームは許可される

おお、それ勘違いしてました。じゃあ、 iOS 限定のライブラリとか、 platforms: [.iOS(.v13)] とかじゃダメなのか・・・。 (edited)

omochimetaru

これはビルドする内側に使うものなのか。外側から見た互換性の宣言ではないのか。

The value is passed as-is to the Swift compiler’s -swift-version flag.

だそうです。 (edited)

2:38 AM

.version("5.1)" とかやっても。

たしかに5.1モードでビルドしようとしてる事と5.0モードからライブラリを利用できない事は厳密には別ですね。 (edited)

iOS 限定のライブラリ（ SwiftUI のサポートライブラリ）とかは、 platforms: [.iOS(.v13)] のように書いておけば、サポートされてないプラットフォームには単にビルドエラーになるから OK ？

5.0以前ならIdentifiableを自分で定義すればコンパイルはできると思うけどライブラリとしての意味はないですね

koher

iOS 限定のライブラリ（ SwiftUI のサポートライブラリ）とかは、 platforms: [.iOS(.v13)] のように書いておけば、サポートされてないプラットフォームには単にビルドエラーになるから OK ？

そうですね、platform指定はコンパイルより前にチェックされるので

2:42 AM

ん？いや違うか

2:43 AM

「ビルドエラーになるからOK」で行くなら今も話は簡単で何もしなくて良さそう

2:43 AM

ビルド前にエラーにしたいという話の流れでいけば

2:44 AM

全部のplatformを書かないといけないけど

omochimetaru

「ビルドエラーになるからOK」で行くなら今も話は簡単で何もしなくて良さそう

言及がないプラットフォームは許可される

の文脈ではそうだけど、 SwiftUI なら iOS 13 が必須なので。

そもそもplatformは未知のものが将来追加される事があるから

2:44 AM

結局ビルドエラーまで行っちゃうケースは厳密には排除できないと思う

omochimetaru

結局ビルドエラーまで行っちゃうケースは厳密には排除できないと思う

そもそも「言及がないプラットフォームは許可される」から禁止はできないのでは？

koher

そもそも「言及がないプラットフォームは許可される」から禁止はできないのでは？

そういうことですね

今そのへんSwiftPMが丁寧にカバーできてるのってAppleプラットフォームだけなので、そこだけ指定するくらいだと思ってます

2:45 AM

強い気持ちで禁止する方法は個別に#if書くしかないような

platforms 書かなかった場合は何でも OK だけど、 platforms: [.iOS(.v13)] みたいに書いたときは iOS 以外で使えなくなると思ってたんですよね。それが勘違いなら問題ないです。

[] も [iOS()] も、tvOSに対してはビルド可能で同じ意味と思ってた

// swift-tools-version: 5.6 これがダメだったっていうのがよくわからなかったんですけど、5.6なら使う方はSwift 5.6以上だから問題なさそうに思うんですけど違いますか？

Kishikawa Katsumi

// swift-tools-version: 5.6 これがダメだったっていうのがよくわからなかったんですけど、5.6なら使う方はSwift 5.6以上だから問題なさそうに思うんですけど違いますか？

Identifable 使うだけで、 platforms 指定がないとビルドエラーになります。 Swift 5.6 でビルドしてもそれ以前の Swift からそのバイナリを利用することはできるので、ビルドするツールのバージョンとサポートされる言語のバージョンは別じゃないでしょうか？

2:50 AM

platforms The list of supported platforms with a custom deployment target.

Identifable 使うだけで、 platforms 指定がないとビルドエラーになります。

これはライブラリを書く側の話ですよね？使う側の話と思ってたので勘違いしていました。

koher

Identifable 使うだけで、 platforms 指定がないとビルドエラーになります。 Swift 5.6 でビルドしてもそれ以前の Swift からそのバイナリを利用することはできるので、ビルドするツールのバージョンとサポートされる言語のバージョンは別じゃないでしょうか？

tools-versionが高いとPackage.swiftをそもそも読むことができないので

Kishikawa Katsumi

Identifable 使うだけで、 platforms 指定がないとビルドエラーになります。

これはライブラリを書く側の話ですよね？使う側の話と思ってたので勘違いしていました。

ああ、わかりづらい言い方でしたね。 Identifiable を利用するライブラリを作りたいという話でした。

koher

Identifable 使うだけで、 platforms 指定がないとビルドエラーになります。 Swift 5.6 でビルドしてもそれ以前の Swift からそのバイナリを利用することはできるので、ビルドするツールのバージョンとサポートされる言語のバージョンは別じゃないでしょうか？

Identifiableが使えるか否かというのは、ツールチェインに含まれる標準ライブラリのバージョンとデプロイ先とOSのバージョンの組み合わせで決まるので、その2つは絡み合ってると思います

使う側がSwift5.6ツールチェーン以上であることは担保されますよ

そうか。それなら swift-tools-version に合わせてビルド可否を切り替えてくれるのが正しいのか。現状はそうなってないけど。 (edited)

Swift 5.6 でビルドしてもそれ以前の Swift からそのバイナリを利用することはできる

こっちは使う側の話だと思いますが、バイナリをライブラリ提供者側で提供しなければ使う側はわかってやってることなのでこれはしょうがないと思います。 (edited)

swift-tools-versionを5.1以上に指定していればavailabilityチェックによる丁寧な診断が出て嬉しい

koher

そうか。それなら swift-tools-version に合わせてビルド可否を切り替えてくれるのが正しいのか。現状はそうなってないけど。 (edited)

いや、「新しいツールチェーンを使いつつ、言語バージョンを設定で下げる」運用はありえて、そのときにその方法では適切にブロックはできないという問題はあります

2:54 AM

ビルドエラーになる、で良いと個人的には思いますけど。

そうか。利用先も Swift 5.6 コンパイラだけど低いバージョンの Swift でビルドもあり得るのか。ややこしい。 (edited)

swift-tools-version:, #if compiler : ツールチェーンバージョン #if swift: 言語バージョン(ツールチェーンバージョンより低い事がある)、swiftLanguageVersion: や -swift-version で指定する。 (edited)

MLKitをSwiftPMに対応させようと四苦八苦しているのでFramework周りに知見がある方助けてください。 MLKitは、CocoaPodsでのみ提供されており、ビルド済みのframework形式で配布されておりarm64 simulatorではビルドできないですが、XCFrameworkは作成できるので対応を試みました。 ビルドエラーは出なくなったので、依存関係は解決できてそうですが、Code Signまわりがおかしいのかうまく行っていません。試みた手順はここにまとめてあります。 https://date.notion.site/WIP-MLKit-SwiftPM-1f037fc18c834898851fc8d091dce613 コードはここにあります。 https://github.com/d-date/google-mlkit-swiftpm

WIP: MLKitをSwiftPMで扱えるようにする

Swift Package Managerで3rd partyのライブラリを扱えるようにするには、repositoryにPackage.swiftを含めることで解決しますが、repoが公開されていないものや、ビルド済みのframework形式で配布されている場合にはそのままSwift PMで扱うことができません。

GitHub - d-date/google-mlkit-swiftpm: Experimental for building Goo...

Experimental for building Google MLKit for iOS in Swift Package Manager - GitHub - d-date/google-mlkit-swiftpm: Experimental for building Google MLKit for iOS in Swift Package Manager

1

FirebaseのPackage.swiftにはMLVisionが入ってないんですね

歴史的経緯で独立しました

frameworkとヘッダファイルあればxcframeworkの再構築は出来そうな気がするが

XCFrameworkの再構築はできた

依存は無かったことにして固めて動かすworkaroundを取って何とかしたことがある

依存関係についてはクリアしていて、ビルドエラーもなくなったけど、デバイス実行時にエラーになるから、Dynamic FrameworkのCode Signがあやしいと思っている（先に記事見てもらえると助かる）

エラーのとこは見たけど、CodeSignかはわからんなって感じ

3:32 PM

似たようなことしてエラー解決したケースあるから情報出しただけだベ

なるほどね。なんか足りんのかなぁ

因みに僕が何とかしたとのはGoogleMapsSDKで

書いてないこととしては、.bundle が含まれているのがあって、それをBuild Phaseにコピーしているというのがある

構成としてGoogleMapsBaseとGoogleMapsCoreがあるんだが、この依存関係が実行時に壊れてる(だったと思う、記憶は定かで無い)で

3:34 PM

最終的にBaseの方にCoreの中身も全部組み込んでビルドすることで、何とかなった。GoogleMapsCoreはdummyファイル一個ぶち込んで消えないようにだけした、という (edited)

3:34 PM

結構正気ではない解決になってる

なるほど。今はMapsもXCFrameworkが提供されているからSwiftPMde

3:37 PM

そのまま使えそうだけど、CocoaPodsからいじくるのなかなかしんどいねw

Carthageあったけどそのまま使うのは無理だったんよ…

3:38 PM

この時は、ああわかった

FirebaseのCarthageも今思えば難しかったね

GoogleMapsCoreが、ヘッダファイル無しの.aだけだったから

3:39 PM

それ単体をxcframeworkにするのは無理筋だったんだ。

create-xcframeworkで.aをヘッダありでもうまく変換できた試しがないw

うーん、そういう要素がないなら、私の経験は役に立たなさそうだな

うーむ、もうちょっとエラーがわかりやすかったらなんとかできそうなんだけどなー

3:40 PM

どうもありがとうね

「ヘッダ無しのframeworkが存在する場合、それを依存に持つライブラリ側にframeworkの中身を渡して一緒にビルドする、ヘッダ無しのframeworkには代わりにダミーファイルを定義する」

3:41 PM

これでした。

なるほどwなかなかハードやなw

暇なときにリポジトリ落として色々試してみるよ役に立たなさそうですまんの

うん、遊べるようにはしてあるから試してみてもらえると

MLKitFaceDetection.framework と MLKitBarcodeScanning.framework はStatic Frameworkだけど、アプリケーションパッケージ（Example.app）に含まれてしまっていることが直接の原因だと思う。

4:36 PM

再現方法は、

4:39 PM

上記の手順（https://date.notion.site/WIP-MLKit-SwiftPM-1f037fc18c834898851fc8d091dce613）を一通りやって、https://github.com/d-date/google-mlkit-swiftpmのワークスベースを開いてビルドします。するとExample.appは生成されるけれども、デバイスへのインストール時に Could not inspect the application package. Domain: com.apple.dt.MobileDeviceErrorDomain Code: -402653103 のようなエラーでインストールに失敗する。

同じ症状です！

このとき、デバイスのログを見てみると（XcodeからOpen Console、だっけ）、

確かにいますね

で、上記に書いたようにConsoleを開いて、インストールしようとしているデバイスのログの受信を開始して、再度インストールしようとすると、こういうエラーが出ているのがわかる。

0x16d5ab000 -[MIBundle _validateWithError:]: 47: Failed to load Info.plist from bundle at path /var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.WVoNf1/extracted/Example.app/Frameworks/MLKitBarcodeScanning.framework; Extra info about "/var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.WVoNf1/extracted/Example.app/Frameworks/MLKitBarcodeScanning.framework/Info.plist": Couldn't stat /var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.WVoNf1/extracted/Example.app/Frameworks/MLKitBarcodeScanning.framework/Info.plist: No such file or directory

4:48 PM

（ログは膨大なので Example.app などのキーワードでログをフィルタすると良い。その上で installd プロセスが出力しているログを探すと見つかる。） (edited)

4:49 PM

これはアプリに含まれるFrameworkはInfo.plistがないとダメなのだけど、それが無いというエラー（だと思う）。つまりこのFrameworkはStatic FrameworkなのでアプリケーションパッケージにEmbedされることを想定してない（のでInfo.plistもない）。

4:51 PM

で、ひとまずそれが原因であることを確認するために、Xcodeから Products/Example.app をShow Finderして、 Example.app パッケージをShow Contentsして Frameworks フォルダからMLKitFaceDetection.framework と MLKitBarcodeScanning.framework を削除します。（他の人にもわかるように手順を書いています。） (edited)

1

4:53 PM

で、２つのFrameworkを取り除いた Example.app を直接XcodeのDevice and SimulatorsのインストールしたいデバイスのところにDrag & Dropします。これはインストールに成功するはずです。２つのFrameworkを取り除かずに同様の操作をすると、同じエラーで失敗します（メッセージも同じ。XcodeがやってることをGUIでやっているだけ）。

4:54 PM

なので直接の原因はStatic Framework（正確にいうとInfo.plistが含まれていないFramework）をアプリケーションパッケージに含めてしまっていること、だと思います。

4:55 PM

直し方はちょっとよくわからない。SwiftPMになんかEmbedさせない設定があるならそれが良さそう。もしくはStatic Linkを指定したりできないだろうか。

4:55 PM

最悪、XcodeのScript PhaseあたりでFrameworkを取り除く、という操作をすると成功すると思う。

ありがとうございます！！！生成するlibraryにtype: .staticをつけてstatic linkにしても解決しないので、なんかバグっぽいですね。

5:01 PM

で、２つのFrameworkを取り除いた Example.app を直接XcodeのDevice and SimulatorsのインストールしたいデバイスのところにDrag & Dropします。

これは取り除いたあとにRun without Building (^ + ⌘ + R)でも成功します (読者向け） (edited)

なるほど！Run without Buildingか。

5:01 PM

SwiftPMのDiscord（Slackだっけ？）で聞くとわかるかなあ。

これか https://swift-package-manager.herokuapp.com

通常Static FrameworkのXCFrameworkを作る場合、XXX.framework/XXX はstatic archiveファイルになっているはずなんですが、MLKitBarcodeScanningはオブジェクトファイルになっているのがおかしそうです。

Podfileでuse_framework!してるのがよくない？

ダウンロードしてるだけだからそこは関係ないと思う。

たしかに

CocoaPodsは https://dl.google.com/dl/cpdc/bfc93c9fa703fe9e/MLKitBarcodeScanning-2.1.0.tar.gz を落としてくるだけ（他の人のために書いています）。

XCFrameworkの作り方ですね。元のPods配下にインストールされるMLKitBarcodeScanningは既にfatオブジェクト（.o)になっていて、make-xcframeworkがオブジェクトとして分離してしまっているので、そこでアーカイブし直せば良いと思います (edited)

ar MLKitBarcodeScanning、で.aにしたらいいのかな？（コマンドはうろ覚え） (edited)

ためしてみます

2

5:10 PM

お、MLKitBarcodeScanningをアーカイブにしたらembedされなくなってますね。

おおお！

お、いけるんじゃね。

やった手順をかきます

5:13 PM

make run で MLKitBarcodeScanning.xcframeworkを作った後、

cd ./GoogleMLKit/MLKitBarcodeScanning.xcframework/ios-arm64/MLKitBarcodeScanning.framework/ mv MLKitBarcodeScanning{,.o} ar r MLKitBarcodeScanning MLKitBarcodeScanning.o ranlib MLKitBarcodeScanning rm MLKitBarcodeScanning.o

を実行してクリーンビルド (edited)

5:16 PM

MLKitFaceDetectionにも同様の作業をするとインストールできるようになりました。

すごい！

というわけで、xcframework-makerにオブジェクトライブラリの場合に↑のステップを追加するのが良さそうですね

1

なかなか手応えのあるトラブルシューティングだった。

5:20 PM

チームプレイって感じだ。

このパターン攻略できたので、これでほとんどの古いライブラリはSwiftPMに移行できるんじゃなかろうか。

SwiftPM CocoaPods Wrapperみたいなものが作れそう。

CocoaPodsならある程度パターン化されてていけそうですね

5:23 PM

今回の知見もさっきの記事にまとめておきますね。

2

Example.xcworkspaceに含まれるPackage.swiftの

 dependencies: [ .product(name: "MLKitBarcodeScanning", package: "google-mlkit-swiftpm"), .product(name: "MLKitFaceDetection", package: "google-mlkit-swiftpm"), ]),

google-mlkit-swiftpm にしろって言われた。Xcode 14だからかな？

あーそっちみるのか。repoつくるときローカルと名前変えたんですよね

あ、謎はすべて解けた。

あとFaceDetectionに.bundleがいるんですけど、元のコードでBundle.main経由で取得しているだろうから、Moduleに加えずに、Build Phaseでコピーしているというワークアラウンドも存在します。 MLKitはSwiftPMのつらみの全部盛りって感じ。

リソースのLookupの失敗は完全に実行時に起こるものだから怖いですしね。

5:34 PM

arコマンドのオプション難しいな。ロングオプションないのか。

わからんw

ar -h usage: ar -d [-TLsv] archive file ... ar -m [-TLsv] archive file ... ar -m [-abiTLsv] position archive file ... ar -p [-TLsv] archive [file ...] ar -q [-cTLsv] archive file ... ar -r [-cuTLsv] archive file ... ar -r [-abciuTLsv] position archive file ... ar -t [-TLsv] archive [file ...] ar -x [-ouTLsv] archive [file ...]

毎回man見てます

5:35 PM

ハイフン付けない派がある

つけなくてもいいんだ。

5:36 PM

ar r ってなんやろって思ってた。

手元でもインストールに成功してMakefileを修正したので記事をアップデートしました。 https://date.notion.site/MLKit-SwiftPM-1f037fc18c834898851fc8d091dce613 https://github.com/d-date/google-mlkit-swiftpm 直接参照できるように、とgit-lfsでトラックしてみたけど、SwiftPMってgit-lfs対応してないんやな…

MLKitをSwiftPMで扱えるようにする

Swift Package Managerで3rd partyのライブラリを扱えるようにするには、repositoryにPackage.swiftを含めることで解決しますが、repoが公開されていないものや、ビルド済みのframework形式で配布されている場合にはそのままSwift PMで扱うことができません。

GitHub - d-date/google-mlkit-swiftpm: Experimental for building Goo...

Experimental for building Google MLKit for iOS in Swift Package Manager - GitHub - d-date/google-mlkit-swiftpm: Experimental for building Google MLKit for iOS in Swift Package Manager

1

いいですね

6:50 PM

CocoaPodsにしか対応してないFirebaseのフレームワークってもうMLKitくらい？ (edited)

より複雑なものにも遭遇しています。こちらはビルドスクリプトが整備されてるのでやりやすいかもしれない？ https://github.com/BelledonneCommunications/linphone-sdk

GitHub - BelledonneCommunications/linphone-sdk: Mirror for linphone...

Mirror for linphone-sdk (https://gitlab.linphone.org/BC/public/linphone-sdk.git) - GitHub - BelledonneCommunications/linphone-sdk: Mirror for linphone-sdk (https://gitlab.linphone.org/BC/public/lin...

7:19 PM

ニッチなんでMLKitほどの需要はなさそうだけども

これは意外とビルドパラメータを変えるだけでいけたりしないかな

あらゆる（ほとんど？）のFrameworkをSwiftPMでインストールできるようにする、というソリューションだから「MLKit（やSwiftPM未対応のあらゆるFramework）をSwiftPMで〜」のようなタイトルの方がいいかも？

タイトルちょっといじっておきました。 Notionだとそのまま公開できて便利なんだけどSEOが良くないので、適切な媒体に移しておこう。

zenn.dev がいいかな

ところでSwiftPM向けに無償で使えるXCFrameworkをアップロードできる場所がほしいのだけど、どこかにないかな

githubのrelease使えるのでは

100MB超えるから無理なんだよね

あれ100mbまでなのか

Releaseはわかんない。gitは無理。

https://docs.github.com/ja/repositories/releasing-projects-on-github/about-releases

リリースについて - GitHub Docs

2:42 AM

releaseは2gbまでいけるよ

おお、じゃあ一旦そこでやるかぁ

Notionは閉じてこちらに移しました https://zenn.dev/d_date/articles/cd4ce3b2b5c29d

あらゆるライブラリをSwiftPMで使えるようにする

Notionのほう、消さずにリンクを置くのがよかったんじゃない。

たしかに！そうしました

generate-xcodeproj ついに消されちゃった… https://github.com/apple/swift-package-manager/pull/5748

Remove generate-xcodeproj command by neonichu · Pull Request #574...

3

ついに消えたのか

おー…

2:49 AM

理由なんだっけか…

元々deprecatedにされてたんでメンテ打ち切りですかね、思ったより早かった

niw

理由なんだっけか…

XcodeがSwiftPMを直接開けるようになったときからdeprecatedでした

なるほど

2:52 AM

メンテ打ち切りか。

今日だてさんに相談させてもらっていた件ですが取り急ぎarm64-to-sim試したところ、残念ながら条件満たしておらずでした arm64シミュレータへの適用はいったん諦める方針で直近調整してみます。もろもろありがとうございました ※イベント終わっちゃったので、こちらのルームで

1

SPMは現状Debug/Releaseの2種類のBuild Configurationしか持てないと思うんですが、App上でImportした場合、AppのBuildConfigurationとSPMのBuildConfigurationってどこで紐付いているのかってご存知の方いらっしゃったりしますでしょうか？

5:25 PM

AppのDebugビルドのときにはSPMもDebugになっていてReleaseはReleaseにそのままなっているけど、Active Compilation Conditions などが引き継がれるわけでもないからどこで紐付いているんだろうと気になった感じで........

Shinichi Katayama started a thread. 10/8/2022 7:59 AM

Xcode の Resolve Package… がむげんに終わらない問題があって、どうやらSPMのfindCycleの実装がだめっぽい

2:49 AM

https://github.com/apple/swift-package-manager/blob/75877ea8304339a5e54da6638f2e476f3f47b406/Sources/PackageGraph/PackageGraph%2BLoading.swift#L866

swift-package-manager/PackageGraph+Loading.swift at 75877ea8304339a...

The Package Manager for the Swift Programming Language - swift-package-manager/PackageGraph+Loading.swift at 75877ea8304339a5e54da6638f2e476f3f47b406 · apple/swift-package-manager

7

https://github.com/apple/swift-package-manager/pull/5839

Avoid redundant checks in cycle detection by fcanas · Pull Request ...

Dramatically improve speed of cycle detection for large or well-connected manifest graphs. Motivation: Loading a project with a large or well-connected package graph in Xcode can be very slow. Xcod...

2

3:31 PM

上の修正パッチ出ました

3:32 PM

(なおこの方は同僚です)

bioがtwitterだ

3:32 PM

3

3:33 PM

この表やばくないすか？

そうなんすよー、現状のやつやばいんですよ

指数的に重くなってたのがメモ化効いて直るんか

いま左下なのでつらい

もしかするとうちもめちゃくちゃ恩恵うけるかも

右下になりたい

3:34 PM

なお手元では10分超えてる模様

今見たらPackage Dependenciesが40個あった

3:34 PM

40あってこれだと宇宙終わりそうだから同じ問題は踏んでないのかなあ (edited)

依存グラフの形状によるかな…

なるほど。

https://github.com/fcanas/manifest-cycle-bug

GitHub - fcanas/manifest-cycle-bug

Contribute to fcanas/manifest-cycle-bug development by creating an account on GitHub.

↑マージされた。Xcodeのアップデートに期待…

おお〜　恩恵あると良いな。

Codesign厳しすぎてSIPありだとXcodeのハック困難なんだよなあ (edited)

2:55 PM

非常に面倒

swift package pluginって、PackagePlugin や Foundation 以外のパッケージをimportできないみたいな縛りってあったりしますか？

dependenciesが書けるからなんでもimportできそうだけどどうなんでしょう。

6:47 AM

swift build --arch x86_64 --arch arm64` ってアーキテクチャを複数指定すると自動的にファットバイナリを作ってくれるんですね。（Macで実行した場合だけ？）そして .build 以下のディレクトリ構成が全然知らないカタチになった。

そのオプション使うとxcodebuildバックエンドになるんじゃなかったかな

そういう仕組みか！全然違った出力になるのも納得だ。

6:55 AM

Macの場合だけ特別にそうなるってことか。

最近しばしばハマってた現象がはっきりしてきた。

8:19 AM

一度タグを打ってパッケージをプッシュした後、他のプロジェクトからそれを依存としてロードしたとする。

8:19 AM

その後、同じタグを別のコミットに打ち直すと、

8:20 AM

以後そのパッケージに依存するプロジェクトが、下記のようなエラーでビルドできなくなる。

error: Revision adc03993975f0a784daeb6fbfb7e1b70dc8f7554 for codabletotypescript remoteSourceControl https://github.com/omochi/CodableToTypeScript version 2.2.0 does not match previously recorded value 96c462e820ecdae0566695b0ecd81c6fee1ec167

8:20 AM

で、これを解決するためには、 proj/.build proj/.swiftpm $HOME/.swiftpm/cache を削除しても駄目。

8:21 AM

ちなみに $HOME/.swiftpm/cache は $HOME/Library/Caches/org.swift.swiftpm へのエイリアス。

8:22 AM

この問題を解決するためには、 $HOME/Library/org.swift.swiftpm/security を削除する必要がある。

1

そもそも同じタグを打ち直すのはダメじゃないかw (edited)

タグを打って、それを取り込む作業をしてて、ちょっとしたミスに気がつく事がよくあるんだよね。まだ誰も気づいてないからこっそり直したい。

8:23 AM

ユーザーが居るライブラリなら revision を1個進めたほうが良いと思う。

ユーザー居なくてもrevision進めた方が良いよ

8:24 AM

タグ打ち直す想定してソフトウェア作られてないし

これ面倒ですよね。僕も Library/org.swift.swiftpm の存在知らなくてよくハマってました

あ、 $HOME/.swiftpm/security が $HOME/Library/org.swift.swiftpm/security へのエイリアスにはなってるな。

タグを打つ前にブランチ対象に十分に試すとかで、ミスった状態でタグを打たなくて良いようにするだとか。とかく、一度付けたタグを消したり変更したりしたら、方々で不具合が出るのはそれはそう、って感じがしました。

tarunon

タグを打つ前にブランチ対象に十分に試すとかで、ミスった状態でタグを打たなくて良いようにするだとか。とかく、一度付けたタグを消したり変更したりしたら、方々で不具合が出るのはそれはそう、って感じがしました。

ブランチ対象だと、swiftpmが依存の依存を固定するロジックが変わるから別の変な事が起きたりしてやめた。

8:27 AM

(ブランチではなく)バージョンタグを打った状態で組み込み作業をテストしないと完全な確認ができないんだよね (edited)

spmでbeta含んだtagを評価できたっけ

8:27 AM

3.1.4-beta1みたいな

できますね。

rcタグでもちゃんとsemverで処理できるのか。それはありだな。

僕はよく 0.1.0-beta.2 とか使ってます。

じゃあそれで。betaナンバリングでやって、確認終わったら外したのをリリースします

やや余談ですが、 sem ver では 3.1.4-beta1 ではなく . を挟んで 3.1.4-beta.1 にしておかないと、 beta 9 と beta 10 の順序がおかしくなってしまうので要注意です。

1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0

https://semver.org/lang/ja/

1

-beta1 でも -beta9 までは文字列比較でうまくいっちゃうのかｗ

8:38 AM

-beta1 < -beta10 < -beta2 で 10のときに戻ってきちゃうからドットが要るんですね。

はい。割と罠な気がする。

8:39 AM

人間だと雰囲気でパースしちゃうから。

つい最近 ZIPFoundation というライブラリにタグ打ち直しをやられて大変面倒でした... https://github.com/weichsel/ZIPFoundation/issues/253

Re-used version tag 0.9.14 causing build issues with SPM · Issue #2...

I believe the developer has pushed version tag 0.9.14 for commit 1b662e2e7a091710ad8a963263939984e2ebf527. Previously this same version tag 0.9.14 was on commit 7254c74b49cec2cb81520523ba993c671f71...

1

やっぱりpluginは外部パッケージをimportできないなぁ

10:00 AM

標準の Process とか使いづらいのでTSCBasicをいれようと思ったけど、importできなかった・・・

えー、それは作りにくいなあ。

1:12 PM

ソースコードの形でバンドリング（？）するようなツールの需要が生まれる？

基本的にはexecutableターゲットをまず作るのでそっちで必要な機能を用意して

1:17 PM

pluginターゲットはそのexecutableを叩くだけなので問題ないはず・・・

あ、そういうものなんですね。

icemanが困ってるのは、その「executableを叩く」部分の実装でFoundation.Processがヘボくて嫌だという話だと思います

私はTSCのProcessから Foundation.Processに戻ってきたからFoundation.Processそんな悪くないと思ってる。

https://github.com/apple/swift-evolution/blob/main/proposals/0332-swiftpm-command-plugins.md#example-2-formatting-source-code

2:09 PM

プロポーザルにのってる例がわかりやすいです。

// swift-tools-version: 5.6 import PackageDescription let package = Package( name: "MyFormatterPlugin", dependencies: [ .package(url: "https://github.com/apple/swift-format.git", from: "0.50500.0"), ], targets: [ .plugin( name: "MyFormatterPlugin", capability: .command( intent: .sourceCodeFormatting(), permissions: [ .writeToPackageDirectory(reason: "This command reformats source files") ] ), dependencies: [ .product(name: "swift-format", package: "swift-format"), ] ) ] )

2:10 PM

↑.plugin() で定義する MyFormatterPlugin は swift-format パッケージの swift-format executable product に依存を宣言していて・・・

2:10 PM

import PackagePlugin import Foundation @main struct MyFormatterPlugin: CommandPlugin { func performCommand( context: PluginContext, arguments: [String] ) async throws { // We'll be invoking `swift-format`, so start by locating it. let swiftFormatTool = try context.tool(named: "swift-format") // By convention, use a configuration file in the package directory. let configFile = context.package.directory.appending(".swift-format.json") // Iterate over the targets in the package. for target in context.package.targets { // Skip any type of target that doesn't have source files. // Note: We could choose to instead emit a warning or error here. guard let target = target as? SourceModuleTarget else { continue } // Invoke `swift-format` on the target directory, passing a configuration // file from the package directory. let swiftFormatExec = URL(fileURLWithPath: swiftFormatTool.path.string) let swiftFormatArgs = [ "--configuration", "\(configFile)", "--in-place", "--recursive", "\(target.directory)" ] let process = try Process.run(swiftFormatExec, arguments: swiftFormatArgs) process.waitUntilExit() // Check whether the subprocess invocation was successful. if process.terminationReason == .exit && process.terminationStatus == 0 { print("Formatted the source code in \(target.directory).") } else { let problem = "\(process.terminationReason):\(process.terminationStatus)" Diagnostics.error("swift-format invocation failed: \(problem)") } } } }

2:11 PM

↑MyFormatterPlugin のコードでは、 context.tool(named: "swift-format") という特殊なAPIを通して、依存として宣言したexecutableのビルドされた実体を表すオブジェクトを取得し、

2:12 PM

そこに swiftFormatTool.path.string でファイルパスが書いてあるので、後は Process でそれを発火する。 (edited)

基本はpluginにそんなにコード書かないから問題ないですね僕はおもちさんが言ったように↑のようなコードでstdoutとstderrを取得しようとしてめんどくさく思った感じです

Pipe作ってってやつね。まあTSCのはuts8Stringみたいなのがプロパティにあるしね。

たしかに↑の作例もまさにpipe出力が何も処理されてないなw

2:29 PM

https://github.com/SwiftGen/SwiftGenPlugin/blob/stable/Plugins/SwiftGen-Generate/Plugin.swift swiftgenの作例もやってなかった、、、 (edited)

SwiftGenPlugin/Plugin.swift at stable · SwiftGen/SwiftGenPlugin

SwiftGen plugin for SPM. Contribute to SwiftGen/SwiftGenPlugin development by creating an account on GitHub.

let stdout = Pipe() process.standardOutput = stdout let stderr = Pipe() process.standardError = stderr try process.run() process.waitUntilExit() if let data = try stderr.fileHandleForReading.readToEnd(), let error = String(data: data, encoding: .utf8) { print(error) } ...

まあでもこんな感じでしょ。Foundation.Processでもまあいいんじゃないかなあ。

ちゃんとやろうするとスレッドセーフを考慮するのと絞りカスを取り出す操作が必要だったような？

2:32 PM

macOSだといらないかもしれない？

ケースによったら前後が混ざったりするかな。

2:33 PM

バッファをゼロにしたりできなかったかな。。。

上のケースはProcessの終わりまで待っててreadToEnd()まで読んでるから読めるだけ読んでるんじゃないかな。

正しい使い方これですね　https://github.com/apple/swift-corelibs-foundation/blob/091f867def06b62b0034e6e73e43f4d39357eda2/Tests/Foundation/Tests/TestProcess.swift#L564-L591

Streamで読んでるところ（L577-581）のところが並行に呼ばれる可能性があるからクリティカルセクションで囲うのはわかるけど、終わったあとのreadToEndを囲う必要あるのかな？

stdoutPipe.fileHandleForReading.readabilityHandler の実行が task.waitUntilExit() が終わるまでに、終わる保証が無いのかも (edited)

なるほどね。

3:31 PM

そうなのかも。あと途中のを読む必要あるのかな。最後のL587-589だけだと欠けてしまうのかしら。

バッファが溢れるんじゃないですか？

それはシステムのパイプ容量を超える可能性があると思います。

3:32 PM

かぶった

3:32 PM

もしくはパイプが満タンだと送り側(ここではtask内部のプロセス)のwriteが失敗するかも？どうだろう。

理解しました。ありがとう。

3:34 PM

たしかにちゃんとやろうとするとこうなるのは大変だな。

3:35 PM

stdoutStringみたいなのがあるTSCを使いたくなるのはわかる。

まあ出力が途切れたりクラッシュしたりしても大して問題ないpackage pluginみたいなのだと雑にやってもいいでしょうね

xcodebuildコマンドを複数回呼ぶCLIのツールを作ったときはTSCのProcessSetが便利だと思った。

3:40 PM

確か標準のProcessはそういうのなくてCtrl+Cで全部終了するみたいなのは面倒だった気がする。

へえこんなのあったんですね。便利そう

https://discord.com/channels/291054398077927425/304939011904897024/1034489423213105192 5.7 向けの PR もマージされてた

12:07 AM

次の Xcode に反映されててほしい

Xcode 14.2 RCが来たけど、SwiftPM側にtag切られてないから今回のリリースはないんかなー https://developer.apple.com/documentation/xcode-release-notes/xcode-14_2-release-notes

14.2 来てたんですね

4:25 AM

リリースノートの内容的に新しい OS のサポートくらいしか変化がなさそう

PackagePlugin、外部モジュールが使えないのはまあ良いとしても、Package.swiftでdependenciesを書くことはできるのはなんなんだ？

4:13 AM

あ、executable productのビルド依存関係を書いているだけってことか？ (edited)

@giginet SwiftPMって、ビルドエンジン(ソースファイルとかオブジェクトファイルの依存関係に基づいて実行計画を立てるやつ)として llbuild を使っているんだけど・・・

6:37 AM

llbuildは実はllbuild2っていう新しいのが開発されていて

6:38 AM

https://github.com/apple/swift-llbuild2/blob/main/Docs/index.md

Remote execution llbuild2 provides data structures that enforce that action specifications are completely defined. This allows clients of llbuild2 to implement any kind of execution engine to power the action graph resolution. Through these interfaces, it would be possible to support common remote execution APIs such as Bazel's RE2 protocol.

6:39 AM

llbuild2は、↑にかかれている通り、リモート実行がアーキテクチャに組み込まれているんだよね

6:40 AM

で、「Bazel's RE2 protocol」がなんだかわからんけど多分Bazelのリモート実行(RE?)APIの設計をパクってるんだと思う、互換性とかはよくわからんが

6:40 AM

なので、SwiftPMの下請けをllbuildからllbuild2にマイグレートしたら、SwiftPMもリモートビルドできるようになりそう、っていう話があるんだけど

6:42 AM

このあたりが1年ぐらいなんの音沙汰も無い気がするから、 appleの展望がどうなっているのかとか、技術的な詳細としてはどういう難しさがあるのかとか知りたい、なんならやっちゃってほしい

6:42 AM

LINEはなんか大規模ビルドの改善に本気っぽいけど、Swiftプロジェクトとしての本命はこの道なんじゃないかと個人的には思ってるんだよね (edited)

なんならやっちゃってほしいw

2

6:44 AM

しかしこうBazelへの移行や出戻りで消耗するよりは素直な道なきもする

昨日メルカリのブログ見たけど頑張る人がBazelに乗り換えるのはハードすぎるから。

2

これ実現したらその先にhttps://twitter.com/tarunon/status/1604892966669074432?s=46&t=ZvIGOnS6fn2GNJN5-jd7eQ の世界観がある気がしてる

uounɹɐʇ (@tarunon)

Xcode Cloudでビルドキャッシュが提供されて、皆が何も考えなくても恩恵に預かれるようになって欲しいね

6:44 AM

メルカリのあれは凄いよ、偉業だ

Yuta Saito

しかしこうBazelへの移行や出戻りで消耗するよりは素直な道なきもする

そうそう。Bazelでやりたいことを、SwiftPMが実現するのが綺麗だとは思うんだよね。

tarunon

メルカリのあれは凄いよ、偉業だ

うん、めっちゃすごいとは思う。

tarunon

これ実現したらその先にhttps://twitter.com/tarunon/status/1604892966669074432?s=46&t=ZvIGOnS6fn2GNJN5-jd7eQ の世界観がある気がしてる

リモートビルドのワーカーとしてクラウド借りれる状態がXcodeに統合されてたらめっちゃ楽だよねぇ〜

Xcode Cloudって言うからには、名前からそういうの期待してたんですよね

RE2 Server llbuild2 can perform execution on build servers that implement Bazel's RE2 APIs. There are many OSS build servers that you can stand up for development.

6:50 AM

互換性もなんかしらありそうな雰囲気

6:50 AM

llbuildについてはこの動画が多分良くって https://www.youtube.com/watch?v=b_T-eCToX1I llbuild2は謎に包まれている、よくしらん

LLVM

2016 LLVM Developers’ Meeting: D. Dunbar “A New Architecture for Bu...

1

6:51 AM

https://forums.swift.org/t/llbuild2/36896

Llbuild2

Hi all, Almost 4 1/2 years ago, we open sourced llbuild alongside Swift and the Swift package manager. At the time, llbuild was still fairly new, but it's design has largely stood the test of time, powering SwiftPM builds as well as other products like Swift playgrounds and Xcode's XCBuild build system. And in that time, llbuild has driven a lo...

6:51 AM

最初のアナウンスは↑これかな。２年経っちゃった。

ふむ

6:54 AM

よさそう

1

6:56 AM

やってみるか

おお

6:59 AM

この辺資料が少なくて多分いろいろコード読んだり動かしてみるしかわからないと思うけど、深堀りすると実装とかアーキテクチャで面白いこととか出てきそうな気はします。

時代はbazel (ただし、75%の人がいなくならない限り)

niw

時代はbazel (ただし、75%の人がいなくならない限り)

75%って何の数字ですか？

omochimetaru

75%って何の数字ですか？

https://apnews.com/article/elon-musk-twitter-inc-technology-social-media-1a9005b6653b07b5764ed61053554d1f

Report: Elon Musk plans to cut 75% of Twitter workforce

SAN FRANCISCO (AP) — Elon Musk plans to lay off most of Twitter’s workforce if and when he becomes owner of the social media company, according to a report Thursday by The Washington Post .

niw

https://apnews.com/article/elon-musk-twitter-inc-technology-social-media-1a9005b6653b07b5764ed61053554d1f

あとで否定したけど、蓋を開けてみたら結果的にそうなった

75%ってすごいな・・・

3:25 AM

別に人数が減ってもコード資産が消えるわけじゃないのでBazelが必要ならそれは変わらない？

まあでも、雇いすぎでしょってのはあった。

3:26 AM

変わらないけど、Bazelやってたひとたち全員いなくなったのでね…

ええ！

3:26 AM

引き継ぎが大変だ・・・

3:26 AM

ビルド環境職人全滅はしんどいですね

iOS やってる人数20分の1になった

niw

iOS やってる人数20分の1になった

もうおわりだ

指で数えられるようになったからなあw

丹羽さんハードコア20倍界王拳だ・・・

https://twitter.com/niw/status/1605363576905994240

Yoshimasa Niwa (@niw)

久しぶりに所謂「クソコード」(設計も実装もなにも正しくない、そしてユーザーにバグを起こしてる)を見つけて悲しくなった。過去のことなんだけど、コードレビューで防げた筈なのに防げてないので、原因を理解したいと思った。採用がダメだった、チームの構成がダメだった… いろいろ考えられるな。

3:28 AM

でもこういうことが起こってたわけで、人数多いってことは裏があって…

3:28 AM

ここ数ヶ月はソフトウェアというより経営サイドの学びが多すぎる

1

実際丹羽さんが残ったってことはエース級だけの少数精鋭になってて快適そう。でも20倍は流石に無理に見える (edited)

イーロンとゼロ距離なのでそこはまあとてもいい勉強になる

3:30 AM

それ以外はまあお酒の場が必要

1

でも昨日イーロン投票で負けちゃったよ(なんだったんだ、あれ (edited)

CEOは降りるけどさっきプロダクトのトップには残るって言ってたね

1

ほんとに現場と話してるんですね＞イーロン

流石にswift pm関係ないのでやめよう、でも年末年始東京いるのでその時に続きをw (edited)

3

3:33 AM

あとつまり、bazel やるにはある程度人手がいるという、まあそういうわけで、、

なるほど

東京いないけどめっちゃ続きを聞きたいｗ

1

と言うか人が多いからbazelが必要な規模になるので、本来はそうなってれば人がいるはずなのに

3:34 AM

人がいなくなった場合はどうすればwという特殊事情

koher

東京いないけどめっちゃ続きを聞きたいｗ

名古屋と京都にも居る時がある予定

1

niw

名古屋と京都にも居る時がある予定

まじですか。でももし東京で集まるなら東京行ってもいいかも・・・

3:37 AM

omochimetaruにも長らく会ってないし。

会ってないんだっけ。 ↓僕はこれ行こうとしてます。 https://discord.com/channels/291054398077927425/380329942505750529/1054611662168129566

https://www.eventbrite.com/e/try-swift-tokyo-meetup-tickets-485367646697

try! Swift Tokyo Meetup

try! Swift is for developing in the Swift language an international community for the latest applications. See detail on https://tryswift.jp

3:38 AM

これ行く

3:40 AM

わいわいなんとかもあるのかー

omochimetaru

会ってないんだっけ。 ↓僕はこれ行こうとしてます。 https://discord.com/channels/291054398077927425/380329942505750529/1054611662168129566

多分2019年のiOSDC以来会ってない。同じ会社にいるのにｗ

2

3:41 AM

それならtry! Swift参加しよかな。"Sales start in 20 minutes"ってめっちゃタイムリーだ。

niw

わいわいなんとかもあるのかー

tryで人が東京に来るチャンスだということで @giginet が併設してくれた。

なるほど、そういうタイミングだったのか。じゃあわいわい&try! Swiftで東京行こかな。

あとちょっとで開始

お、ぜひ！わいわいは今日ページ出しますね

1

4:28 AM

niwさんもぜひお会いしたいですねー

1

https://github.com/apple/swift-package-manager/blob/main/Tests/PackageLoadingTests/PD_5_7_LoadingTests%20.swift

swift-package-manager/PD_5_7_LoadingTests .swift at main · apple/sw...

The Package Manager for the Swift Programming Language - swift-package-manager/PD_5_7_LoadingTests .swift at main · apple/swift-package-manager

12:55 AM

このファイル名にスペースが入ってるのは意図してないような気がする (edited)

1

https://github.com/apple/swift-package-manager/pull/6079

Rename test file that contains a space. by niw · Pull Request #6079...

Motivation: There is a test file that name contains a space unexpectedly, caused by commit c3e5cee. Modifications: Rename it to remove a space. Result: There is no files that contains unnecessary s...

1

8:41 AM

意図してなかったらしい

お客様の中に、SwiftPMで引っ張ってきたdependencyのdebug informationについて詳しい方いらっしゃいますかー Xcode SettingのOptimization Level -Onone Clangも-oなのに、poするとvariable not foundで困ってます。

まずコンパイラに -g が渡されてるか確認するかなぁ

swiftコマンド経由はdebugならわたってそうだけど、Xcodeはよくわからんなぁ https://github.com/apple/swift-package-manager/blob/main/Documentation/Usage.md#debug

swift-package-manager/Usage.md at main · apple/swift-package-manager

The Package Manager for the Swift Programming Language - swift-package-manager/Usage.md at main · apple/swift-package-manager

ソースに #if debug 埋め込んでそれっぽいか見るとか、derived data に dsym とか dwarf があるかみるとか

めんどくさくなってprint埋め込んでなんとかしてしまった

9:15 AM

全然別件で多分結構な人が困ってそうなワークアラウンド。参照元は記載してあります。 https://gist.github.com/d-date/9745e4c8a13c85a98b3f812d2299727c (edited)

Workaround for previewing SwiftPM resources

Workaround for previewing SwiftPM resources. GitHub Gist: instantly share code, notes, and snippets.

1

Swift 5.8でも swiftSettings: [ .enableUpcomingFeature("BareSlashRegexLiterals") ] ↑使わないとRegex使えないっぽいのなんでや？

そういえば#//#使てるな。いつから普通に使えるようになるんでしょうね。

https://github.com/apple/swift-evolution/blob/main/proposals/0354-regex-literals.md

swift-evolution/0354-regex-literals.md at main · apple/swift-evolut...

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swift-evolution/0354-regex-literals.md at main · apple/swift-evolution

9:54 AM

プロポーザルだと Status: Implemented (Swift 5.7) Upcoming Feature Flag: BareSlashRegexLiterals (implemented in Swift 5.8) って書いてあって

9:54 AM

5.7ではupcoming featureとして使えて、5.8で通常実装されるって意味かと思ったんですが・・・

9:55 AM

Implementation: apple/swift#42119, apple/swift#58835 Bare slash syntax /.../ available with -enable-bare-slash-regex

9:55 AM

もしかして、5.7では -enable-bare-slash-regex で使えるよ、という話と

9:55 AM

5.8からは Upcoming Feature Flagで有効化すれば使えるよ　という話が書いてあるだけで

9:55 AM

正式実装がいつになるとは言ってないのか・・・？

9:56 AM

To accommodate the cases where source may be broken, /.../ regex literals will be introduced in Swift 6 mode. However, projects may adopt the syntax earlier by passing the compiler flag -enable-bare-slash-regex or the upcoming feature flag BareSlashRegexLiterals. Note this does not affect the extended delimiter syntax #/.../#, which will be usable immediately.

9:56 AM

書いてあった。

9:56 AM

ソース互換性を破壊するから6から入る機能らしい。

9:56 AM

5系の間はオプションが必要なものらしい。

ソース互換性はこれからもちょいちょい壊れるのか。ちょっと困るな。

// こういうのとか /* let regex = /[0-9]*/ */ // こういうの x+/y/

9:59 AM

コメントのスラッシュとか演算子のスラッシュが

9:59 AM

(これまではそうではなかったのに)正規表現になってしまうケースがあるらしい。 (edited)

難しいな。これはどう対処したらいいんだろう。普通に考えるとRegexはリテラル以外の書き方もあるし#//#もいけるからRegexの判定を甘くしたらいいんじゃないかと思うけどそういうもんじゃないのかしら。

10:02 AM

上のパターンが壊れるってことは割り算とかコメントの方を直せっていうことですよね。

qux(/, /)

10:03 AM

↑これとかワリとどうしようもなさそう。

Kishikawa Katsumi

上のパターンが壊れるってことは割り算とかコメントの方を直せっていうことですよね。

そうです。

10:03 AM

foo(/a, b/) // Will become regex literal '/a, b/' qux(/, !/) // Will become regex literal '/, !/' qux(/,/) // Will become regex literal '/,/'

10:04 AM

↑これはaとかbには前置単一スラッシュ演算子とか、謎の演算子を自作してるケースしか該当しないｗ

Regexリテラルは良いと思うけどさすがにまったく使わないプロジェクトもあるのでそれは受け入れられるんだろうか。

10:04 AM

スラッシュのカスタム演算子がなければ大丈夫なのか。

Kishikawa Katsumi

Regexリテラルは良いと思うけどさすがにまったく使わないプロジェクトもあるのでそれは受け入れられるんだろうか。

5系の状態でregex literalっぽいものだけ警告出す機能がないと洗い出せないし、

それならまあかなりレアケースか、、、？

そういう警告があっても警戒してなくて6が来て困る人はちょっと要るかなあ

Kishikawa Katsumi

それならまあかなりレアケースか、、、？

prefix slashはpointfreecoのcasepathがそうですね確か

それは大変なことになるんじゃないか。

10:06 AM

まあ影響が大きいのはParserを直したりするんだろう。

Kishikawa Katsumi

スラッシュのカスタム演算子がなければ大丈夫なのか。

最初に書いた例のコメントのやつはカスタムなくても踏みそうですね普通の除算演算子の例は書いてなさそうだけど発生しないのか・・・？

10:07 AM

qux(/,/)

10:08 AM

↑これは普通の除算を関数として渡す形だな

10:08 AM

reduce(0, +) みたいなやつ

SwiftSyntaxのIssueで Color(1/255, 2/255, 3/255) みたいなのが誤動作するっていうのは前にみた。

おーほんまや

10:09 AM

In order to help avoid a parsing ambiguity, a /.../ regex literal will not be parsed if it starts or ends with a space or tab character. This restriction may be avoided by using the extended #/.../# literal.

10:10 AM

↑これがあるから Color(1 / 255, 2 / 255, 3 / 255) って、隙間あけた除算にすればいいみたいですね。

なんでスペースを開けるといけるのかしら？

そういう風に正規表現リテラルの文法を弱くしてあるって事ですね

Kishikawa Katsumi

難しいな。これはどう対処したらいいんだろう。普通に考えるとRegexはリテラル以外の書き方もあるし#//#もいけるからRegexの判定を甘くしたらいいんじゃないかと思うけどそういうもんじゃないのかしら。

Regexの判定を甘くしたらいいんじゃないかと思うけどそういうもんじゃないのかしら。

まさにこれ

10:11 AM

SwiftのRegexは / a / を許さない

/ a / は正規表現リテラルとして無効なんすか？

Kishikawa Katsumi

/ a / は正規表現リテラルとして無効なんすか？

そうです。そういうときは #/ a /# こっちを使う。 (edited)

正しい正規表現に見えるけど。

10:12 AM

あ、そうなんだ。

10:12 AM

え、難しいな。

先頭にスペース来るマッチパターンを実際ほぼ書かないと思うので良い作戦だと僕は思ってます (edited)

スペースプラスとか書かないかな。だいたい \s+ な気もするけど。

そのときは # 付ける・・・

難しいけどその辺が妥協点かな。JSもスラッシュを含む正規表現リテラルは書けないしな。

SwiftPMのバグ？(Xcodeのバグ?)についてです。 pluginがexecutableを実行してコード生成するようなパッケージがあって、libraryがそのpluginで生成されたコードを使用するという構成にした場合に、iOS, macOSなどではビルドできるのですが、macCatalystでエラーでビルドできません。エラー内容はシンプルでディレクトリが存在しないというエラーです。Finderから見てもそのディレクトリは作成されていませんでした。

sandbox-exec: execvp() of '//Users/zunda/Documents/GitHub/SampleLibrary/DerivedData/SampleLibrary/Build/Products/Debug/SampleExec' failed: No such file or directory Command PhaseScriptExecution failed with a nonzero exit code

検証用コード: https://github.com/zunda-pixel/SampleLibrary 手順: Clean(Shift + Command + K)してからビルドすると上のエラーになります。何かのバグのように思えるのですが、どういった対処(報告)をすれば良いでしょうか？ (edited)

8:59 AM

SwiftPM単体としてはビルド環境はmac向けしか無いと思うので、 macCatalystのような他環境向けのビルドはXcode固有の挙動なので、 Xcodeのバグ報告をするのが良いと思います Appleの設置してるfeedback assistantというのが報告窓口サービスになります https://feedbackassistant.apple.com (edited)

1:30 AM

ただfeedback assistantのXcode + SwiftPM関連のバグは、報告しても全然見てもらえないし直りもしないので、

1

1:30 AM

SwiftPMプロジェクトの方に報告したほうがリアクションはもらえるかもしれません

1:30 AM

https://github.com/apple/swift-package-manager/issues 報告先はリポジトリのissue欄で良いと思います

1:31 AM

「その件はXcodeの問題だからXcodeの方に報告してくれ」って言われるだけかもしれません。

やっぱりfeedback assistantのXcode関連って見てくれなさそうですよね。ありがとうございます。どちらにも報告したいと思います!

僕は9か月前の報告が無視されてますね・・・

2

報告したバグに対して「iOS16.1で直しました」っていう通知が年明けてから届いたりもして全部遅い印象がありますね…(iOS16.1は10/24リリース)

2

昔catalystのやばいバグを直した時は中の人とwebexしてすぐ治った思い出

12:11 AM

なんかmultithreadingでカジュアルに複数スレッドから同じポインタアクセスしてて確率的にアプリがクラッシュするっていう感じだった気がする

Xcode CloudでBuild Tool Pluginが pluginWorkDirectory にwriteしようとするときに、Could not exportになる事象があって困ってるんだけど、誰かワークアラウンド知りませんか。ローカルでは動くし、IDESkipPackagePluginFingerprintValidationも設定済みなんだけど…

sandboxの作り方が違うのかなぁ

Apply build tool plug-in “SwiftLintPlugin” to target “XcodeCloud” in project “XcodeCloud” 2023-06-20T04:33:59.374110103Z 2023-06-20T04:33:59.374194651Z /usr/bin/sandbox-exec -p "(version 1) 2023-06-20T04:33:59.374307420Z (deny default) 2023-06-20T04:33:59.374420261Z (import \"system.sb\") 2023-06-20T04:33:59.374513971Z (allow file-read*) 2023-06-20T04:33:59.374657054Z (allow process*) 2023-06-20T04:33:59.374770999Z (allow file-write* 2023-06-20T04:33:59.374865119Z (subpath \"/private/tmp\") 2023-06-20T04:33:59.374981670Z (subpath \"/private/var/folders/n0/3380ckd54yl7lfjbwcy83w740000gn/T\") 2023-06-20T04:33:59.375082724Z ) 2023-06-20T04:33:59.375173795Z (deny file-write* 2023-06-20T04:33:59.375297157Z (subpath \"/Volumes/workspace/repository/XcodeCloud\") 2023-06-20T04:33:59.375377665Z ) 2023-06-20T04:33:59.375458446Z (allow file-write* 2023-06-20T04:33:59.375564433Z (subpath \"/Volumes/workspace/DerivedData/SourcePackages/plugins/XcodeCloud.output/XcodeCloud/SwiftLintPlugin\") 2023-06-20T04:33:59.375699684Z )

ログを発掘してみたけどこの辺かな。

6:44 AM

Build Pluginは/private/tmpに書き込むのが安全なのかな。 /private/var/folders/n0/3380ckd54yl7lfjbwcy83w740000gn/T って NSTemporaryDirectory()で返ってきそうなパスだけどそこが違うのかもしれない。

あのやばいAPIだ

呼ぶたびに毎回変わったりしないかな。

それ系のAPIはVolumeが複数あるデバイスだと挙動がアレかもしれない

6:48 AM

(やばい理由)

6:49 AM

参考: https://twitter.com/niw/status/1654718263094394880

Yoshimasa Niwa (@niw)

I found that using NSDataWritingAtomic may crash app, so it’s unsafe option.

pluginWorkDirectoryっていうのを見逃してたな。調べてみる。

わからんかったけど、XcodeCloudで書き込みできるところとは違うところに書き込むということが起こってそう。

あるいは、XcodeCloudで書き込もうとしているパスが書き込めないような場所になってるか。

これは、ファイルは書き込めるが、中間ディレクトリが書けないようになっているみたいでした。動いたのでめでたしめでたし

なるほどー

ファイルOK、ディレクトリだめってことか。気をつけないとハマるやつだな。

SE-0273 の configration dependency がテストも実装されているのに PackageDescription には実装されていないのはなんでだろう… https://github.com/apple/swift-package-manager/blob/0100d605e304e57b147b1172ed1442e27f9a6c52/Tests/BuildTests/BuildPlanTests.swift#L792-L915

swift-package-manager/Tests/BuildTests/BuildPlanTests.swift at 0100...

The Package Manager for the Swift Programming Language - apple/swift-package-manager

nanasi

SE-0273 の configration dependency がテストも実装されているのに PackageDescription には実装されていないのはなんでだろう… https://github.com/apple/swift-package-manager/blob/0100d605e304e57b147b1172ed1442e27f9a6c52/Tests/BuildTests/BuildPlanTests.swift#L792-L915

.xcodeprojバックエンドでConfigurationによって依存が切り替わるようなターゲットを表現できなかったからっぽいですねぇ。 https://github.com/apple/swift-package-manager/pull/2428

Conditional target dependencies proposal implementation by hartbit ...

This is the implementation of the target dependency proposal that I plan to write a proposal for. I implemented it so that it only affects the build plan, but not the dependency resolver. This allo...

なるほど… SwiftPM 側が頑張れば実現できるのか、 Xcode 側の改善待ちなのかどちらだろう？

どうなんですかねー、SwiftPMパッケージのビルドってまだXCBuildつかってんのかな

package.swiftの中で環境変数を読み込んで分岐を仕込んで、パッケージ定義を切り替え可能にする裏技あるけど、 Xcodeでswiftpackageを開いてる時にその環境変数渡す方法は無いですかね？ (edited)

CLIで環境変数設定して xed . などCLI経由でXcodeを起動するとXcodeのSPMでも参照できました (edited)

2

おお、そんな方法は思いつきませんでした！ありがとうございます

ローカル開発だけ時間短縮でXCFramework化したRealmを利用したくて、パッケージをすり替えるのに使いました........!!

2

まさに同じ事をやろうとしていますw

1

@giginet パッチ3つに分けて出しましたこれで現時点でこっちでわかった事を全部共有しました

1

ありがとう〜

@giginet @freddi Xcode15-beta3のCI通すの不可能だからmain向けにも出した、起きてたらapprove押してCIつけてほしい

草

4:13 PM

すみません。明日やろうとしてました

ないんすよ、GitHub Runnerが (edited)

もうcontributorにするわ

やったー

xcode15-betaブランチはmainに追従してないから追従させた方が良い

1

4:15 PM

日曜に直しておきます

4:16 PM

コラボレーターにしました

4:16 PM

ご協力ありがとうございます

お、できた、自分で起動できた

4:17 PM

PRに対するCIの起動にapproveが先に必要な設定初めて見たけど

4:18 PM

macOS runnerが高いから？

First Time Contributorに対してはスパム対策としてApproveが必要にできる設定があるんすよ (edited)

あー、初見さんだけなのか

4:19 PM

それは確かにバランスいい感じするな

うーん

8:34 AM

ストリームでログを出す挙動をログレベルによって切っていた場合に

8:34 AM

エラーが起きた時に、そのエラーにまつわる以前のログを出したい需要と共存させるのってどういう感じだ

8:35 AM

ログレベルによらずファイルには出しておいて、エラーのときはそれ見てね、みたいな感じかなあ・・・

8:36 AM

まあいいか　メモリに溜めとけ

ビルドログは割とバカにならない量になりそう

そうなんだけど・・・Scipioの既存実装が少なくともそうだから、ファイルに流すのは今後の課題にしとくｗ

なるほどw

FIXME かいとこ。

xcbuildの丁寧な処理やったらめっちゃ見やすくなった

1

xcodeのビルドログのところって、項目別に分かれてて折りたたんだりできるけど、あの辺の仕組みはこのログオブジェクトで構造化されてることがわかった

10:55 AM

最近のxcodeはtask IDが見当たらない、みたいな意味不明なエラーメッセージが出る事があるけど、それも多分これの話なんだとわかった

@omochimetaru 土日風邪ひいててようやっと見始めました。貢献ありがとうございますこれmainに向いてない奴、基本的にmainに向けていって良いですか Xcode15のブランチにマージすると管理が大変になるので

giginet

@omochimetaru 土日風邪ひいててようやっと見始めました。貢献ありがとうございますこれmainに向いてない奴、基本的にmainに向けていって良いですか Xcode15のブランチにマージすると管理が大変になるので

お疲れ様です。うちの赤ちゃんも熱出てます。 main向けのプルリクを別途作って出してありますけど、宛先変えるのでも良いです。

1

あ、本当だ。同じのmainにも出してくれたんですね。じゃあ一旦xcode15-beta3向けのは全部閉じさせてもらって、mainにマージして、Xcode15互換のブランチをもう一回整備して案内しますね（名前も変えた方が良さそうだし）

了解です。 xcode15-beta3をmainに追いつかせるコミットもプルリク作って出してあります

このブランチは廃止して新しく作ることにします。命名もマズいし。 mainとの差分は見てるsnapshotのバージョンが変わる程度なので

8:56 AM

結構mainから置いてかれてるし

なるほど

@giginet https://github.com/giginet/Scipio/pull/88#discussion_r1279101055 これどう思います？要するに BuildConfiguration が struct なのにプロパティを let にしてるのが無意味でイケてないと僕は思っています。実際にここでやっているように、setterを外部から実装可能なので、結局書き込み禁止できてないからです。最初からvarで良かったのです。で、こういうextensionはその型に対する汎用的なもので、このファイル固有の目的で必要なものというわけではないので、他の場所からも見えて良いと思うのです。ただ定義するファイルがここだと不適切かなと思っています。 (edited)

[main] 重複してmodulemapが入力されないようにする by omochi · Pull Request #88 · gig...

#85 の内容をmain向けに提出します。

理解しました。internalでよいかな

internalで良いとして、なんかそういう「Scipioの依存先ライブラリを拡張するファイルをまとめるディレクトリ」とか

4:10 AM

ファイル管理戦略が必要だと思いますが、どうしたい？

4:11 AM

ここにおいてあるのだと、見逃して、同じようなものを再実装してしまう恐れがあると思います

@Yuta Saito static library + library evolution ってナンセンスですよね？ libevoはABIを維持して、アプリをリビルドせずに差し替えたライブラリと動的リンクを成功させるための仕組みであって、 static libraryだったら、差し替えるには再リンクしないといけないから、前提としてAPIが維持されているなら、libevoじゃなくてもリンクできるのでABI互換性は要らない。？

1

omochimetaru

@Yuta Saito static library + library evolution ってナンセンスですよね？ libevoはABIを維持して、アプリをリビルドせずに差し替えたライブラリと動的リンクを成功させるための仕組みであって、 static libraryだったら、差し替えるには再リンクしないといけないから、前提としてAPIが維持されているなら、libevoじゃなくてもリンクできるのでABI互換性は要らない。？

Swift 5.7でビルドして配布したstatic libraryをライブラリ側をリビルドせずに5.8でビルドしてるアプリにリンクできるというメリットが一応あるはず (edited)

5:10 AM

ライブラリとアプリをビルドするサイクルが同じなら基本的に必要ないはず

あれ？Swift5.7でビルドしたstatic library(libevoなし)ってSwift5.8でのアプリのビルドにそのまま突っ込めないんだっけ？

5:12 AM

バイナリのリンク時の下位互換性はあるのかと思ってた

5:13 AM

なぜなら言語バージョン間のABI仕様は固定されてるから・・・

swiftmoduleに言語バージョン間の互換性がないので、library evolutionなしだとそもそもアプリのコンパイルに失敗するんじゃないかな

バイナリもlibrary evolutionのときだけresilientなインターフェースになるっぽいな

ヘッダ(swiftmodule)が読み込めないレベルなのか (edited)

5:23 AM

swiftinterfaceつけとけば・・・と思ったけど、エンドユーザ向けにはそれこそがlib evoのときの挙動なのかな。

はい、swiftinterfaceは違うバージョンのコンパイラでswiftmoduleを生成するのに必要な情報を持ってる感じですね。で、-enable-library-evolution はそれを吐く (edited)

むーなるほどー

5:27 AM

scipioで --static --disable-library-evolution を指定するのがめんどくさいので

5:27 AM

--static なら --disable-library-evolution は infer されて良いんじゃないかと思ったんだけど

5:28 AM

そうとも言い切れない感じだなあ

それらは独立ですね

5:28 AM

--static で--enable-library-evolutionは動かないんすか

自分は試してないんだけど動かないってぎぎにゃんが言ってた試してみるか

5:32 AM

[Atomics#29] /Users/omochi/github/apple/swift-atomics/Sources/Atomics/autogenerated/Primitives.native.swift:22:8: error: no such module 'Builtin' import Builtin ^

5:33 AM

いや

5:33 AM

disableでもだめだ

5:33 AM

なんだこれ

https://github.com/apple/swift-atomics/blob/2ff28f87327de7b1c7f7974be60258bf9dfcf0f3/Package.swift#L25C35-L25C35

あたらしくなりすぎた

5:34 AM

beta3系でやらないとだめだな

5:34 AM

いやライブラリを下げるか

5:35 AM

swift-atomicsはいけた。

5:39 AM

[NIOConcurrencyHelpers#28] /Users/omochi/github/apple/swift-nio/Sources/NIOConcurrencyHelpers/NIOLock.swift:154:5: error: deinitializer can only be '@inlinable' if the class is '@_fixed_layout' @inlinable ^~~~~~~~~~ /Users/omochi/github/apple/swift-nio/Sources/NIOConcurrencyHelpers/NIOLock.swift:195:14: error: 'let' property '_storage' may not be initialized directly; use "self.init(...)" or "self = ..." instead self._storage = .create(value: ()) ^ /Users/omochi/github/apple/swift-nio/Sources/NIOConcurrencyHelpers/NIOLock.swift:190:18: note: '_storage' declared here internal let _storage: LockStorage<Void> ^ /Users/omochi/github/apple/swift-nio/Sources/NIOConcurrencyHelpers/NIOLockedValueBox.swift:32:14: error: 'let' property '_storage' may not be initialized directly; use "self.init(...)" or "self = ..." instead self._storage = .create(value: value) ^

5:39 AM

swift-nioでエラーが出るぞ

5:41 AM

disableなら成功した。

disableデフォルトで良いんじゃないですか

xcframeworkはprebuilt binaryを配布するための手段だから

5:42 AM

scipioとしてはenableが基本になるんじゃない？ (edited)

5:43 AM

俺はサーバサイドswiftのプレビルドキャッシュとして使いたくて、ビルドしたxcframeworkを配布する目的はないからdisableがいいけど

ライブラリ開発者が配布用XCFrameworkをビルドするために使うのがメインであればenableが良さそうですね。 Carthageみたいに自分のアプリの依存ライブラリを予めビルドしておきたいという需要ならdisableでよさそう。

1

Scipioとしてはデフォルトで依存グラフ全部ビルドしようとするから、ライブラリ開発者が配布するのは一番のユースケースじゃないんじゃないかと思ってたけど、ぎぎにゃん的にはどうなんだろう (edited)

1

あ、そうか。配布用途だとこの挙動はマッチしてないのか。

scipioはxcframeworkを配布ではなくビルドキャッシュとして使うという特殊な用途なので、library evolutionは無効で良いという感じなんですよね

5:50 AM

有効だと@inlinableとか駆使してるライブラリがビルドできなくて扱いづらい

1

そもそも大抵のライブラリはABIどころかAPIが安定してない

Iceman

有効だと@inlinableとか駆使してるライブラリがビルドできなくて扱いづらい

それはそれでよくわかんないんだよな library evolutionがオンのときとオフのとき、両方でビルドできるように書く方法ってないのかな？

omochimetaru

それはそれでよくわかんないんだよな library evolutionがオンのときとオフのとき、両方でビルドできるように書く方法ってないのかな？

library evolutionがオンならオフのときもビルドできるんじゃないですか？

Iceman

library evolutionがオンならオフのときもビルドできるんじゃないですか？

そのはず

Iceman

library evolutionがオンならオフのときもビルドできるんじゃないですか？

オフのときは、 @inlinable を駆使して高速なモードになってほしいとしたら？ (edited)

omochimetaru

オフのときは、 @inlinable を駆使して高速なモードになってほしいとしたら？ (edited)

そのケースは今のところ救う方法がない気はしますね

1

1. evolution有効に対応して、バイナリ配布されていて簡単に導入できる 2. ソースをチェックアウトして手元でビルドすれば、高速に動作するこの両方を提供できるのが、理想的なライブラリ側のあるべき姿だと思う。 (edited)

5:54 AM

というか、開発中は1で、出荷用は2になってほしいんですよね。

5:54 AM

そうすればそもそものVaporを使うプロジェクトで SwiftPMが壊れた時にクリーンしてフルビルドが遅い、という問題が起きなくなる。

Resilientなコードにしたことでどのくらい遅くなるんだろうか

わからんけど結構遅くなりそう・・・最適化できない場所めっちゃ増えそうだし・・・

ちゃんとクライアント側に露出するところを選べばそこまで遅くないんじゃないかなぁ

Vaporとかだと、Vaporの中もいろいろパッケージが切れてるから

5:57 AM

断面たくさんあるけどそれでもいけるかなあ

5:58 AM

ちょっとした型のコンストラクタとかメンバアクセスとかがインライン化されるのかメソッド呼び出しになってしまうのかは

5:58 AM

でかい気がする

うむーまあインターフェース間のやり取りが多ければそうすねぇ

例えば NIOHTTP1 の中のちょっとした型とかが

5:59 AM

Vapor の中でガチャガチャ操作されたりしている

5:59 AM

現状だとそれの実験もできないの良くないな。ビルドできないから。

https://github.com/giginet/Scipio/issues/91

--disable-library-evolution をデフォルトにしたい · Issue #91 · giginet/Scip...

--disable-library-evolution をデフォルトにしてほしいです。 Library Evolutionは配布用のバイナリライブラリを作るための言語機能です。一方、scipioのツールとしての目的は、依存先ライブラリを事前ビルドして、開発中のリビルド時間を減らすことだと思います。この目的においては、ビルドしたキャッシュとしてのライブラリを再配布することは無いので、 ...

6:09 AM

とりあえずお手紙を出しておいた

バイナリ配布、依存がないライブラリじゃないと実質ほぼ不可能じゃないですか？

6:24 AM

依存先ライブラリのバージョンを指定する方法がないので。

あれ？ないの？

6:24 AM

バイナリ配布って、Package.swiftおいて、その中に xcframework の URLを書くから、そこでdependeciesかけると思っている (edited)

あ、Package.swiftとセットだったらいいのか

使う側も、いきなりURLを指定するんじゃなくて、そのPackage.swiftを指定して、その中のproductとして依存を指定するのが通常のお作法 (edited)

*.xcframework単体のポン置きをイメージしてしまったけどそれはそうか

言い換えるとURL定数を書いたり設定したりするのはライブラリ配布側で、利用側じゃない

Iceman

*.xcframework単体のポン置きをイメージしてしまったけどそれはそうか

言われて気づいたけどxcframeworkをポン置きして、直接 .binaryTarget 作ってねっていう配布方法も一応可能なのか。

6:26 AM

逆に。

てことはプレビルド版とソースからビルドする版を区別したければ環境変数ハックを使うか別Package.swiftにするか、別ターゲットにするかなど必要そうですね

そうですね。そこきれいにやる方法なさそうなんだよな。

omochimetaru

internalで良いとして、なんかそういう「Scipioの依存先ライブラリを拡張するファイルをまとめるディレクトリ」とか

単にBuildConfiguration+Extensionsみたいなファイルで良いと思います

giginet

単にBuildConfiguration+Extensionsみたいなファイルで良いと思います

了解でーす

1

返事遅れてすみません。読みました！応援ありがとう〜 iOSDCまでに正式リリースできるように頑張ります。 Library Evolution無効化の件はissueにコメントしておいたけど、特に強い気持ちはないので、ドキュメンテーションがしっかりされていればどちらでも良いのかなと

2

9:44 AM

おもちさんのパッチは全部取り込むので、こちらでテストしてからタグ打ちますね

omochimetaru

https://github.com/giginet/Scipio/issues/91

対応しました https://github.com/giginet/Scipio/pull/93

Change default value of enableLibraryEvolution by giginet · Pull Re...

closes #91 This PR makes LibraryEvolution to be disabled by default. As discussed in #91, Scipio focuses on preparing frameworks for specific projects. So keeping ABI compatibility is not the prima...

giginet

対応しました https://github.com/giginet/Scipio/pull/93

ありがとうございます！後でみます

@omochimetaru 以前送ってくれた修正ですが SwiftPMが生成しているmodulemapではなく、自作しているmodulemapを正としたのはなにか理由がありますか問題があるケースが見つかったのでどうやって直そうか考えてます

giginet

@omochimetaru 以前送ってくれた修正ですが SwiftPMが生成しているmodulemapではなく、自作しているmodulemapを正としたのはなにか理由がありますか問題があるケースが見つかったのでどうやって直そうか考えてます

単に小さい変更で問題が解決できそうだったからです。ログ周りとかも不便で作業しづらかったので大きな作業を避けました。 SwiftPMが作る動作(1)が残ってる（ただし参照されないようにした）＋自作の生成ロジック(2)も持ってるという現在の状態は設計として望ましくないと思ってます。 SwiftPMが作る動作をオーバライドして、(1)と(2)を統合するのが良いと思ってます。 SwiftPMがxcodebuildにmodulemapを生成させるところの仕組みは MODULEMAP_FILE_CONTENT というパラメータに文字列をいれてやる方法を使っているので、 (2)で持ってる自前のモジュールマップ生成結果をこのパラメータに上書きしてやれば、統合できると思います。生成先のパスも MODULEMAP_PATH かなんかで指定されているので変更できる。問題があるケースというのもそれでうまく解決すると思う。 (edited)

理解しました

6:20 AM

これらが作ってるmodulemap、役割が違うんですよ前者のSwiftPMが生成しているものはバイナリのビルド時に使われる物で、後者の自作しているものは配布されるフレームワークに同梱され、エンドユーザーが使うmodulemap というわけで生成が必要がある

結局clangモジュールとしてヘッダーの可視性を定義してるだけだから

おもちさんがやってくれた変更は、ビルド時に後者を見てビルドするようにするという仕組みになっていて、前者に寄せた方が良いのかなと思ってた

同じようにできるんじゃないかな

giginet

おもちさんがやってくれた変更は、ビルド時に後者を見てビルドするようにするという仕組みになっていて、前者に寄せた方が良いのかなと思ってた

前者に寄せるのは無理なんですよね

1

6:21 AM

SwiftPMが作るmodulemapは、マシンのフルパスが書き込まれてるから配布できない

あ、そうそう

6:22 AM

だからビルド時は前者を使って、後者は配布時にのみ使うということですね

6:22 AM

今ビルド時にも配布用のmodulemapを使っているんじゃないかな

あ、そうです。 > ビルド時にも配布用のmodulemapを使っている配布用のmodulemapでビルドもしてしまう必要があると思う。

6:23 AM

ビルドしてるときと、配布されるフレームワークを利用するときで、結局同じようにヘッダーが解決されてないと、いろいろと無理なはず。

なるほど。わかりました

ビルドするときと配布するときでヘッダー可視性がズレてるようなトリッキーな構成にしてるパッケージは見捨てるしか無いと思う (edited)

ちなみに今起きている問題、依存関係の一部をキャッシュから復元すると、modulemapが生成されていないということが発覚した

scipio自前のキャッシュシステム？

omochimetaru

ビルドするときと配布するときでヘッダー可視性がズレてるようなトリッキーな構成にしてるパッケージは見捨てるしか無いと思う (edited)

そうなんですよね。結構多いけど、そこを無理するのは違うなと思って対応していないです設定で読み替える仕組みはあってもいいのかなとは考えているが･･････

自作してるmodulemapをキャッシュから復元するロジックが入ってないんじゃないか？

そう

6:25 AM

なので直します

まあ、自作してるmodulemapは、xcbuildのビルドグラフシステムからこぼれてるから、そういう意味でもよくないんだよね。

6:26 AM

単純に自作のmodulemapもキャッシュする＋復元してあげるだけで、問題は解決できそうだけど

6:26 AM

根本的にいいのは ↑で書いた(1)と(2)の統合だと思います。

昨日

SwiftPM側が挿入する MODULEMAP_FILE_CONTENTS をなくして自動生成を抑止する
-fmodule-map-file を渡さないようにする
自分で生成したものを MODULEMAP_FILE に渡してFrameworkに含むようにする
-Fで生成したフレームワーク内のモジュールを正としてあつかうようにするという変更を試してみたら、NIOSSLのビルドは維持出来たし動いてそうだ

(edited)

おお

3:48 AM

自分で生成したものを MODULEMAP_FILE にわたすのではなくて、

3:48 AM

MODULEMAP_FILE_CONTENTS と MODULEMAP_PATH を使って、xcbuildに生成させたらどう？

3:49 AM

そのほうがxcbuildのシステム内で完結するよ

それだとフレームワークにコピーが必要になるんですよね

あー足りない動作があるのか

MODULEMAP_FILE_CONTENTS と MODULEMAP_PATH を使うと、DerivedData内にmodulemapが生成されて、それがビルド時に使われるんだけど、Frameworkにはdistributionされない

なるほどね

MODULEMAP_FILEとMODULEMAP_PATH一緒にしたらうまく動かないかな

↑はダメだった

Library Evolutionを有効無効のデフォルトをどうするかって話が前にあったけど、今みたいな2つのSwiftバージョンを頻繁に切り替えることがある場合にEvolution無効だとキャッシュが片方で使えなくて困ったりしないのかな？

切り替えてキャッシュ全滅はベータ併用期はよくやってますね。

Swiftのバージョン切り替えるよりXcodeのキャッシュがおかしくなって全クリアするほうが多いので、そんなに影響ない気もする？

1

Xcodeのインクリメンタルビルドが信用ならんからXCFrameworkをキャッシュに使う、ってことじゃないのでしたっけ？リモートキャッシュでキャッシュを共有したいってほうが主目的なんでしたっけ？ (edited)

あー、scipioの文脈でしたか。それだとxcframeworkでキャッシュクリアを堰き止められて効果ありそうですね

1:03 AM

Library Evolution無効だとSwift切り替え時にxcframework全部作り直しですけど、Swiftバージョン含めてキャッシュ管理すると思うので問題なさそう

なるほどね。

あ、これこの前ギョウザ屋で聞かれた奴か。気付いてなかった (edited)

3:09 AM

icemanの回答の通りですね。XCFrameworkをシステムキャッシュからコンパイラバージョンも含めたキーで復元するので

3:10 AM

例えばXcode 14と15を別ブランチで作業していて、みたいなケースでもむしろリビルドが抑制される

もしかしてそもそもLibrary Evolutionいらなかった説あるのかしらね。

言語にとって、という意味ですか？「アプリそのままでiOS SDKだけアップグレードする」とかの用途があるので必要だとは思います。

言語にとって、という意味。たしかにiOSアプリとシステムライブラリの関係はそうか。

ハードウェアベンダーとかにとってはiOS向けハードウェアを使用するためのライブラリは一回ビルドしたxcframework一回配ればOKになって便利だとは思います。一時期、その手のライブラリを使う必要があってSwiftのバージョンが上がるごとに「ライブラリ新しいのください」とお願いしてて面倒だなぁと思ってました。 (その手のプロプラライブラリを使いたいか？とか別の問題はあるにせよ…) (edited)

1

ソースコードで配布するものについてはLibrary Evolutionでかかる制限と天秤にかけて使わないこともけっこうあるって感じかな。

ソースコードで配布できるなら最適化も効くしそっちの方がいいですねビルド時間がかかるというデメリットはあるけど

今ってパッケージの product名って、Product.name は無視されてリポジトリのディレクトリ名になってる・・・？

12:26 AM

やっぱりそう見える実装: https://github.com/omochi/swiftpm-pkgnmchk-user (edited)

12:26 AM

え、 Package(name:) ってなんの意味があるんだ？？

12:26 AM

しかもxcodeの左のところには Package.name が表示されている

12:29 AM

12:30 AM

.package(name:url:branch:) を使うと定義されてる名前のほうが使える、が、deprecatedだ

12:31 AM

全く違う名前も付けられる・・・ Package.name は結局関係ない

https://github.com/apple/swift-evolution/blob/main/proposals/0292-package-registry-service.md

swift-evolution/proposals/0292-package-registry-service.md at main ...

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - apple/swift-evolution

12:44 AM

package registryを登録している状態だとURL末尾とは別のわかりやすい id というので指定できるらしい　これもちょっと違う話だな

12:48 AM

https://forums.swift.org/t/why-does-swiftpm-use-github-repo-name-and-not-package-swift-name/55085/3

Why does SwiftPM use GitHub repo name and not Package.swift name?

the problem is that when using the package, you have to write, .executableTarget( name: "example", dependencies: [ .product(name: "JSON", package: "ss-json"), ]), but the actual name of the package in the Package.swift is swift-json, and this is what people expect to write in...

12:49 AM

超わかる

12:53 AM

Maxによるとマジで表示にしか使われてないらしい　意味わかんねえ。

12:53 AM

そこまで行くなら表示も identity じゃないと識別子として役に立たないだろ・・・

なるほど...?

apple org のリポジトリだと Package の name とリポジトリ名は意図して統一している感じですよね． (edited)

12:08 PM

https://github.com/apple/swift-syntax/pull/1647

Package.swift: make package name consistent with repo name by MaxDe...

Rest of SwiftPM packages provided by Apple follow a dash-case naming scheme consistent with repository name, usually with swift- prefix. This shouldn't have an impact on SwiftSyntax clients. Fo...

おお、SwiftSyntax から swift-syntax に変更している (edited)

koher

platforms 書かなかった場合は何でも OK だけど、 platforms: [.iOS(.v13)] みたいに書いたときは iOS 以外で使えなくなると思ってたんですよね。それが勘違いなら問題ないです。

古い議論を掘り返して申し訳ないと思いつつ、結局今iOS限定のライブラリーってSwiftPM使う場合無理ですかね…

普通にSwiftPMで作れるんじゃないですかね？ platforms指定に関しては、他のプラットフォームで使えないようにする事はできないですけど、問題ないと思います。

9:13 AM

サポートしていないプラットフォームに対してビルドできることをわざわざ禁止する、って他の言語でもやられないと思います。単にビルドが通らなかったり動かないだけです。

#if !os(iOS) コンパイルエラー #endif

問題は依存してるライブラリーがmacOSの制限があって、platforms にiOSだけ指定してるとmacOSのバージョンが適合できないと言われるし、かと言ってじゃあ platforms にmacOS追加したら今度は import UIKit で怒られるし、全部のファイルに #available iOS つけるのも大変だし…

あーなんかみたことありますねその状況

9:32 AM

みたことあるだけで答えは持ってないですが・・・

SwiftPMの設計に問題がありそうだなあそれ

9:48 AM

依存元のプロジェクトにおいてはmacOSは対象としていないなら、依存先のmacOSサポートはそもそも無視してくれて構わないのに

9:48 AM

依存先に引っ張られてmacOSサポートが依存元側で必要になってしまっている？

9:48 AM

xcodeprojでiOSターゲットから依存してるswiftpm packageとかでもそうなりますっけ・・・？

9:50 AM

全部のファイルで #if os(iOS) // コード #endif

9:50 AM

って包んでやって、iOS以外でビルドするときは空っぽのコードにしちゃえば、とりあえずはビルドできるようにできると思いますが。。 (edited)

xcodeproj側での導入は試してないですねまだ、とりあえずPackage.swiftはこの現象です

Package.swiftをxcode spm integrationで開いた状態ですかね？

9:56 AM

それってスキームのdestinationをiPhoneにしていても

9:56 AM

macの互換性の問題が出ます？

ただそもそもなぜPackage.swiftで入れてるかというと、絶対コンフリクトするからXcodeでファイル管理させたくないから本体を全部Packageにして、Xcodeプロジェクト側はエントリーポイントだけ設ける作りにしたかったからです

ただダブルクリックして開いただけの初期状態はdestinationがmacOSになるので

9:58 AM

プロジェクト本体＋依存先のmacOSビルドに影響されるのは自然だと思います

あー一応XcodeでPackage.swift内包してるWorkspace開いてiOS向けビルドすると特に問題はなさそうです

9:59 AM

ただまあ動作確認で swift build とかしたい時が多々あって…

destinationはこれですね

↑はい、そのやり方なら特に問題ないです

1

swift build を素で打つと、暗黙にmac向けにビルドする話になっているので

10:00 AM

それが問題になるのは仕方ないですね

1

swift build --platform とかほしいw

--sdk とか --toolchain はあるけど

10:01 AM

iOS向けにするときにどうやるのが正しいのか知らないです。。

ですよねー

たしかに platforms: 指定があるのだから --platform iOS って書きたいですね。

10:06 AM

https://forums.swift.org/t/swiftpm-swift-build-for-ios/42517/4

SwiftPM "swift build" for iOS

I was able to get this working for swift-only packages with the below command, However Objc files still fail. swift build -Xswiftc "-sdk" -Xswiftc "xcrun --sdk iphonesimulator --show-sdk-path" -Xswiftc "-target" -Xswiftc "x86_64-apple-ios13.0-simulator"

10:06 AM

頑張ってる人いるけど無理そうだなあ

iphonesimulator向けってのはちょっと違うんですよね…

xcodebuildコマンドで根本のxcodeprojをビルドするのはどうですか？

最悪それも考えられますが、引数が多くて覚えられない自信はありますw

それは、ラップしたシェルスクリプトを一個置いとけばよさそう

ですね、最悪それしかないですよね…（ファイルが乱立してメンテ大変そうw

標準で簡単な方法で済ませたいのはわかります。

Makefileで良さそうに見える

SE-0387 が accept されたので，将来的にはこれに乗っかる形で swift build で iOS 向けにビルドすることもできるようになりそうな気がしてます．実際にそれを試してみた PoC リポジトリが以下にありますし． https://forums.swift.org/t/introducing-an-sdk-for-building-ios-macos-apps-on-linux-experimental/66233

Introducing: An SDK for building iOS/macOS apps on Linux (experimen...

With support for SE-0387 in the works, some of the most important pieces are finally in place to make it super easy to cross-compile Darwin apps on Linux. To show this off, I've put together a proof of concept SDK for compiling iOS and macOS apps on Ubuntu: Once you build and install the SDK, using it is as simple as swift build --experiment...

2

TSC、deprecatedになったけど新しいバージョンがリリースされたな。 https://github.com/apple/swift-tools-support-core

GitHub - apple/swift-tools-support-core: Contains common infrastruc...

Contains common infrastructural code for both SwiftPM and llbuild. - GitHub - apple/swift-tools-support-core: Contains common infrastructural code for both SwiftPM and llbuild.

2

deprecated知らなかった、最近ですか？

11:30 PM

ごちゃ混ぜでバージョン管理できない、って書いてあるけど、分割していくんだろうか

最近だね。６月くらいにこの記述が増えた。

11:37 PM

Processは重宝してるから（他はあんまり）なんか問題起きたらそれだけ切り出せるだろうかとか考えてた。

11:44 PM

SwiftPMからTSCを分離したけどけっきょくあんまりうまいこと分離できなかったって感じかしら。

Kishikawa Katsumi

Processは重宝してるから（他はあんまり）なんか問題起きたらそれだけ切り出せるだろうかとか考えてた。

まあ全体的に小ぶりに実装されてるので使うところだけコピペとかしやすいですよね

Kishikawa Katsumi

SwiftPMからTSCを分離したけどけっきょくあんまりうまいこと分離できなかったって感じかしら。

Foundationより一回り広いぐらいですよね分割して整理するなら swift-foundation も一緒に進めてほしいなあ

ガッツリ依存していてまだまだ外せないから新リリースがいるということなのかな

@giginet https://github.com/giginet/Scipio/pull/104 これもっと詳しく知りたい .framework の組み立てを自前でやるのはわかるけど、 PIF(xcbuild)の利用は続いてるみたいで、 PIFの加工は減ったけど無くなってはないみたいで、結局元PIFの役割はどこまで残ってるのかが知りたいあと、元々それだとビルドできないから加工してたという認識だけど、なぜ加工を減らしても大丈夫なの？ (edited)

Introduce new framework generation process by giginet · Pull Reques...

This PR changes framework generation process. Before Scipio tries to consist of frameworks with PIF. Modify PIF to generate framework by injecting header and linker build phases. But it breaks som...

お、後で書いておく

1

omochimetaru

@giginet https://github.com/giginet/Scipio/pull/104 これもっと詳しく知りたい .framework の組み立てを自前でやるのはわかるけど、 PIF(xcbuild)の利用は続いてるみたいで、 PIFの加工は減ったけど無くなってはないみたいで、結局元PIFの役割はどこまで残ってるのかが知りたいあと、元々それだとビルドできないから加工してたという認識だけど、なぜ加工を減らしても大丈夫なの？ (edited)

返事遅くなってしまった今までProducts以下に作られていたフレームワークにpublicヘッダやmodulemapを直接追加していたが、xcbuildが暗黙的にProductsに対してFramework Search Pathを設定するため、modulemapが重複したりしていて壊れていた（以前のNIOSSLの問題）そこでframeworkの生成をxcbuildだけで行うのは諦めて、単にproductTypeをobjectFileからframeworkに変えて、生成されたバイナリやswiftmoduleから新たにFramework Bundleを別に生成することにした（AssembledFramework） PIFの変更を行っていたのは主にBuild Phaseの追加で、Public Headerの追加は、xcbuildが生成するframeworkでは気にする必要がなくなったので（絶対パスで直接パッケージから読めれば良い）PIFに追加する必要がなくなったという感じです

giginet

返事遅くなってしまった今までProducts以下に作られていたフレームワークにpublicヘッダやmodulemapを直接追加していたが、xcbuildが暗黙的にProductsに対してFramework Search Pathを設定するため、modulemapが重複したりしていて壊れていた（以前のNIOSSLの問題）そこでframeworkの生成をxcbuildだけで行うのは諦めて、単にproductTypeをobjectFileからframeworkに変えて、生成されたバイナリやswiftmoduleから新たにFramework Bundleを別に生成することにした（AssembledFramework） PIFの変更を行っていたのは主にBuild Phaseの追加で、Public Headerの追加は、xcbuildが生成するframeworkでは気にする必要がなくなったので（絶対パスで直接パッケージから読めれば良い）PIFに追加する必要がなくなったという感じです

なるほど！ product typeをframeworkに変える方針でうまくいったのか。これまではstatic libraryかdynamic libraryにしてたんだっけ？

omochimetaru

なるほど！ product typeをframeworkに変える方針でうまくいったのか。これまではstatic libraryかdynamic libraryにしてたんだっけ？

いや、元々frameworkだった。staticArchive/dynamicLibraryに変える方法も試してみたんだけど、rpathが変わっちゃって読み替えないとダメとかでまた面倒だったので、基本はframeworkとしてビルドした方が良いです

ああ、わかった frameworkのままだけど、これまでは内部で出力されたところに追加で介入していたところをやめたのか scipioとしてのフレームワークを組み立てる作業がxcbuildに干渉しないように整理したってこと？

ですです

なるほど。 Productsの方はmodulemapの中身が絶対パスでポータブルじゃなかったりするけど、そういうものは外で作り直す方針にして、バイナリのビルドはなるべくそのまま動かすようにしたのね良さそう

1

Package.swiftの中でPackage.swiftがある場所の絶対パスって取得できますっけ？

環境変数で取れそうな気がする

#filePath?

\(ProcessInfo.processInfo.environment["PWD"]!)でできました。ありがとうございます

11:52 AM

一応filePathもやってみよう

11:53 AM

filePathでもいけそうでした。

cwdがプロジェクトルートであることはSwiftPMは保証しない気がしますねぇ

なるほど

11:55 AM

Dockerfileのビルドが通りさえすればいいので、そこは許容できるかも

Yuta Saito

cwdがプロジェクトルートであることはSwiftPMは保証しない気がしますねぇ

Package.swift を指定するオプションを使うとズレそうね

Linuxだけであればサンドボックス無いから動きはする (edited)

11:56 AM

ちなみに何に使うんですか？

#file は信用できそう　都度コンパイルされてるし

プレビルドのcライブラリをリンクしたくて.linkedLibraryを使ってるんですが、ここ-Lとして渡されるからLDサーチパス内の名前か絶対パスしか使えないんですよね

お行儀のよいやり方としては絶対パスを含んだ.pcを作ってSwiftPMのpkgconfigインテグレーションに任せる、もしくはswift build するときに-Xswiftc -L で渡す、かなぁ

.pcだと自然と動的リンクになりませんかね

11:59 AM

絶対パスでstatic library指定もできるか

あれ、そうなんですか

あわよくばxcframeworkみたいな感覚でバイナリをSwiftPMで配布したかったので、直接指定してリンクすることばかり考えてました

-lXで指定されたライブラリにlibX.soとlibX.aがあるとき普通のリンカは.soを優先するけど、-l:libX.a で指定するとライブラリのファイル名をフルで指定できる

12:04 PM

あー、ビルド済みのものをソースと一緒に配布するってことですか

1

12:10 PM

考えたけどSwiftPMの機能を超えたユースケースなのできれいな方法は無いです… #filePath が一番マシかなぁ (edited)

xcframeworkのLinux版がほしい

つくって

12:12 PM

ターゲットプラットフォームとして"Linux"ってふわっとし過ぎなんですよねぇ

確かに種類がそれなりに限られるappleプラットフォームと違って、Linux系統は種類が多すぎますね

12:14 PM

雑にLinuxと名前をつけると悲劇がたくさん起こりそう

Pythonのmanylinux的なやつが爆誕

結局冷静になってprebuildはやめて丁寧にpkgconfig使いました。

filePathでなんか壊れました？

いや、そこは問題なかったです。単純にお行儀が悪い点と、x86_64とarm64のプレビルドバイナリをそれぞれ作るのが面倒だと思ってやめました

5:20 AM

手作業で作って固めるのはできるけど、CIで作るのを考えると手間

冷静な判断だ

RealmSwiftをSwiftPMで使おうとした時に、 Missing required modules: Realm.Private, Realm, Realm.Swift というエラーが arm64-apple-ios.private.swiftinterfaceで出ているんですが、何が起こっているのか理解したいです。 Dynamic XCFrameworkというのが厄介な感じがしています。 @Kishikawa Katsumi 何かわかりますか？

すごくややこしいことをしている…

6:16 AM

SwiftPMのビルドシステムでは現状RealmSwift.xcframework -> Realm.xcframeworkのbinaryTarget間の依存を記述できないのが根本的な原因ですね

6:19 AM

Realm.xcframeworkの中のmodulemapにRealm.Private, Realm.Swiftモジュールの定義があるんですが、RealmSwift.xcframeworkからそれらを見えるようにする手段が無い。

なるほど。ローカルにおこうとすると100MBを超えるので、git lfsのお世話になるしかなくて辛い。

6:21 AM

現状解決の手立てはない感じなのかなぁ

SwiftPMの将来的な対応はフォーラムで議論されているけど新しい厄介な扉を開けることになりそうで直近の対応は見込めなさそう。 https://forums.swift.org/t/accepting-swiftpm-binary-target-dependencies/60619

ダメか〜実質Podsぐらいしか手立てがない、というかRealm使うべきかはナンセンスなケースだったから使わない方向に倒してもらおうかな。

本当にSwiftPMで使いたい場合ビルド時間を犠牲にして素直にソース形式の依存として使うしか無いかなぁ

いま新規でRealm使うようなケースってあるんですか？

SDKについてくることがあってですね…

1

3

realm/realm-swift見に行ったらそれなりにコミットが活発だった

7:20 AM

最近話題をみないからゆるやかに消えたのかと思ってました

SDKについてくるエグいな　デカすぎんだろ

新しいプロジェクトでSwiftPM使ってインストールしてみたら使えてるっぽいけどどういう構成で問題が起こってるの？なんかXCFrameworkを使う設定がある？

Xcode備え付けのspmと、Package.swift直書きとで挙動に差がありそう

1

あ、Package.swift直書きか。あとでやってみよう。

あとは、Realm直インストールと、sdk経由で引っ付いてきたときでワンチャン差があるかも

SDKにくっついてくるっていうのが難しそうだな。なんかSDKがバイナリ形式でダウンロードする、みたいな感じなんだろうか。

@d_date 差し支えなければ依存しているsdkを教えて貰うのが手っ取り早そうです

4:36 AM

なんやかんや最小再現実験を共有して貰えると、話が早そうではある

tarunon

@d_date 差し支えなければ依存しているsdkを教えて貰うのが手っ取り早そうです

SDKなくても再現すると思うよ。

4:39 AM

もちろん差し支えるのでSDKは教えられないのですが。

1

SDKはXCFramework形式で、Realm.xcframework, RealmSwift.xcframeworkがついてきました。

SDKのインストールはSwiftPMなんですか？

9:07 AM

めっちゃ勘だけどRealmはRealmで入れてSDKの方はSDKだけ入れるっていうふうにするといいんじゃないかと思うけどどうだろう。 Package.swiftにRealmSwiftとSDKが書かれる。

それも最初に実験済みで、かていくんが書いてくれた事象が起こります。 SDKは直入れ、RealmはSwiftPM

そうか。難しそうだな。

buildするときにartifactoryとかからダウンロードするとか

5:43 AM

(git-lfsがアレな場合)

5:44 AM

っていうような作業はswiftpmじゃあ無理なんだっけか

5:44 AM

sandboxed?

できます。binaryTarget指定のときに、URLとchecksumを書いてあげれば大丈夫。 private repoの場合でも、.netrcにPAT書いておけばいいです。ただ、それはRealmがやってくれないとメンテがしんどい。

なるほど

Realmの件、GitHub ReleaseにRealm.spm.zipとRealmSwift.spm@15.2.zip があって、両方ともURLをコピー、Package.swiftに雑に貼る、checksum違うと怒られるのでエラーに書いてある正しいのを貼るでリーズナブルに解決できそうです。

12:25 PM

Dependabotが検知しないのは微妙だけども

xcodebuild -create-xcframework をするときに、以下のエラーが出るんですが、どうやって原因探っていったらいいですか？ Message: "error: unable to determine the platform for the given binary '/var/folders/74/lws4xlls7fg_m4pkl499hp6h0000gn/T/XCFrameworkMaker_2B8CD624-6866-4376-BA29-58C144815E87/ios-device/MLKitBarcodeScanning.framework/MLKitBarcodeScanning'; check your deployment version settings" ビルド済みフレームワークでも成功するものと失敗するものがあって、原因を突き止めておきたいと思っています。（xcframework-makerを使っていますが、失敗するのはxcodebuild -create-xcframeworkです。）

とりあえず-vを付けると細かいサブコマンドがダンプされて深掘りできたりするかも？

MLKitBarcodeScanning.framework/MLKitBarcodeScanning のロードコマンドを otool -l でダンプして、

9:29 AM

まずLC_BUILD_VERSION が存在してるかチェックするのが良いかな？

3

9:31 AM

古いリンカで作られたバイナリだと LC_VERSION_MIN_xxxというロードコマンドを使うっぽくて、もしかするとcreate-xcframework が古いやつを見ないのかもしれないなと。

-verboseは効かないみたい

xcodebuild -create-xcframework -verbose -framework /var/folders/74/lws4xlls7fg_m4pkl499hp6h0000gn/T/XCFrameworkMaker_E10499DC-225D-4875-8D48-871BA5D66070/ios-device/MLKitBarcodeScanning.framework -framework /var/folders/74/lws4xlls7fg_m4pkl499hp6h0000gn/T /XCFrameworkMaker_E10499DC-225D-4875-8D48-871BA5D66070/ios-simulator/MLKitBarcodeScanning.framework -output GoogleMLKit/MLKitBarcodeScanning.xcframework

error: invalid argument '-verbose'.

9:32 AM

otool -l Forumでよくeskimoさんがやってるやつだ

9:34 AM

dumpの仕方あってる？

8.22 KB

あってそうですー。

9:35 AM

どっちも無いなw

ないねw

9:36 AM

成功するFrameworkも貼っておきます

4.04 KB

少なくとも問題はそのフレームワークのリンク時なので、次は実際のリンクコマンドをチェックしたいですね。

d_date

成功するFrameworkも貼っておきます

こっちはあるね

d_date

成功するFrameworkも貼っておきます

こっちにはありますね Load command 1 cmd LC_VERSION_MIN_IPHONEOS cmdsize 16 version 11.0 sdk 16.2

リンクコマンドはどうやって確認したらいいですか？

xcframework-makerってやつがどうやってビルドしてるかによりますねぇ

以前ここでトラブルシューティングしてもらったやつなんだけど、 CocoaPodsで取得したビルド済みバイナリをlipoでextractしてます。そのログはこちら

GitHub - d-date/google-mlkit-swiftpm at bump

10.69 KB

いくつか消えるポイントがありそうですね。

9:45 AM

まずそもそもPodsで配布されてるやつに件のロードコマンドが含まれてるかを確認して、

9:46 AM

次にlipoで分解された直後、arm64-to-simを適用した直後、もそれぞれ確認したいですね

9:46 AM

あ、でも問題になってるのはios-deviceだからarm64-to-simは関係ないのかな

このブランチに挙げているので、お手元でもご確認いただけます。 https://github.com/d-date/google-mlkit-swiftpm/tree/bump arm64-to-simの有無でエラーは変わってないので、関係ないかな。

Google MLKit for iOS in Swift Package Manager. Contribute to d-date/google-mlkit-swiftpm development by creating an account on GitHub.

9:49 AM

CocoaPodsのotool -lのログ

GitHub - d-date/google-mlkit-swiftpm: Google MLKit for iOS in Swift...

8.11 KB

9:49 AM

元からなさそう

そもそも元が腐ってそう

1

3.2.0では問題なかったので、4.0.0が問題か

9:51 AM

公式がSwiftPMもやる気ないし、このことの何が問題なのか伝えるの難しいな。これってBuild Settingsがどうなってたらこうなるっていうのあるんですか？

あー、たしか最近のXcodeで認識されるdeployment target versionの最小値が変わって、古いバージョンを IPHONEOS_DEPLOYMENT_TARGET とかで指定してると無視されるようになったのでそれかも

9:56 AM

mainブランチでチェックアウトされるMLKitBarcodeScanningの LC_VERSION_MIN_IPHONEOSが超古いのでそれかも Load command 2 cmd LC_VERSION_MIN_IPHONEOS cmdsize 16 version 10.0 sdk 10.0

まだバイナリコミットしてないけど、4.0.0になって11.0に上がったはず(それでも古そう)

MLKitのソースってどっかに公開されてるんでしたっけ

されてないのよ

わはは

10:01 AM

これビルドしてる環境の問題だから、手元のXcodeのバージョン下げても意味ないよね？

ですねー

お手上げやな、MLKitやめよう笑

最後の手段です

$ vtool -set-build-version 2 15 15 Pods/MLKitBarcodeScanning/Frameworks/MLKitBarcodeScanning.framework/MLKitBarcodeScanning -o Pods/MLKitBarcodeScanning/Frameworks/MLKitBarcodeScanning.framework/MLKitBarcodeScanning

10:05 AM

これでバイナリに LC_BUILD_VERSION を設定できる

すごい、食品偽造みたい笑試してみよう

1

-set-build-version <platform> <minos> <sdk> という意味になってて、platformの2はiphoneos、7がiphoneos-simulatorです (edited)

すごいな、よくスラスラ出てくるなぁ

色々調べながらしゃべってますw

Yuta Saito

-set-build-version <platform> <minos> <sdk> という意味になってて、platformの2はiphoneos、7がiphoneos-simulatorです (edited)

この数字はこの辺をみると書いてある https://github.com/apple-oss-distributions/cctools/blob/7a5450708479bbff61527d5e0c32a3f7b7e4c1d0/include/mach-o/loader.h#L1315

うわぁこれみたことあるわ。arm64-to-simのMach-O Headerの判定の時に使ってるやつだ

10:12 AM

そしてvtool差し込むにはxcframework-makerやめて地で書いた方が良さそうだ

か、xcframework-makerを改造するか笑

改造するということは、バイナリ見て LC_VERSION_MIN_IPHONEOSあるか判定するってことでしょう？めんどくさいな笑まぁやってみよう

10:15 AM

ちょっと晩御飯食べるので、このあと進捗出たらまた報告します！的確で助かりました！ありがとう！

はーい。チョット進んでよかった。

1

終盤の流れレベル高すぎる

続報：ビルド通りました

めでたい

通ったのもよかったけど、Frameworkのもぐり方がわかってうれしい

結局vtoolでいけました？

いけたいけた。xcframework-makerを改造しました

おーすごい

5:10 AM

賞味期限偽造に成功

現場猫感すごいし、またいつ壊れるかわからんけどw Privacy Manifest対応のためのアップデートなのでどこかでMLKitはがそうw

すごｗ

Static FrameworkにInfo.plistがないと怒られるXcode 15.3の仕様で脱法Info.plistを生成することになったけど、RunとArchiveまでできた

というわけでできました https://github.com/d-date/google-mlkit-swiftpm

Google MLKit for iOS in Swift Package Manager. Contribute to d-date/google-mlkit-swiftpm development by creating an account on GitHub.

まとめた https://zenn.dev/d_date/articles/3bf9e3600f3c4d

XCFrameworkの生成時にプラットフォームがわからないと言われたら

Note: この記事はswift-developers-japanのDiscordサーバーでの @Yuta Saitoさんとのやり取りをもとにGPT-4が執筆をしています。誤解を招きそうなところはこのようにNoteを入れて補足しています。

そんな方法が

だいぶラフにサマリーしてくれてよかった

１から書くより楽そうだしなんかあったら俺もやってみよ

うーん StrictConcurrencyをあるターゲットに指定すると

12:28 PM

そのターゲットから依存してるターゲットのコンパイル時も

12:28 PM

その依存先ターゲットのソースコードに対してSendable checkが入ってるな

12:28 PM

そして依存先の依存先に関しては影響がない (edited)

12:29 PM

Xcodeが余計に表示してるだけなのかコンパイラがそう動いてるのかよくわからないけど

いや、状況によるのかな

12:37 PM

依存先ターゲットの static let が Concurrency unsafe な場合に警告が出るというケースは、そういえばこれまでもあったな (edited)

12:38 PM

それは公開してる側のバグじゃなくて使う側で警告するもの、というだけか

omochimetaru

https://forums.swift.org/t/se-0301-package-editor-commands/44447

ようやく実装が来た！と思ったらなんか SE-0301 とはオプションが違いますね https://github.com/apple/swift-package-manager/pull/7467 (edited)

Adding package dependencies to the manifest programmatically and fr...

Package manifest files are Swift source code, so editing them means working with the source code directly. Introduce a new library based on swift-syntax that allows us to perform targeted manipulat...

すっかり忘れてた

1:03 PM

acceptして実装もあったけどそれが流れてずっと止まっていたのか

ですね

ほんとだｗコマンドがまあまあ違う

1:04 PM

proposal

swift package add-dependency <dependency> [--exact <version>] [--revision <revision>] [--branch <branch>] [--from <version>] [--up-to-next-minor-from <version>]

SE-0301 が accept とは言いつつも無かったことにされてる可能性もありますねw

impl

OVERVIEW: Add a dependency to the package manifest USAGE: swift package add [--branch <branch>] [--from-version <from-version>] [--exact-version <exact-version>] [--revision <revision>] <url> ARGUMENTS: <url> The URL or directory of the package to add OPTIONS: --branch <branch> The branch to depend on --from-version <from-version> The minimum version requirement --exact-version <exact-version> The exact version requirement --revision <revision> A specific revision requirement --version Show the version. -h, -help, --help Show help information.

1:06 PM

dependencyはURLのことだから結構似てるな add-dependency → add --from → --from-vrersion だな

SE-0301 に合わせる修正が入ってたんで，思い出されたみたいですね．

shell completionが対応していないサブコマンドを対応させようと調べてたら、swift package completion-toolがswift package completion-commandにしれっと変わっているのを知った。 https://github.com/apple/swift-package-manager/pull/7336

Rename Swift*Tool to Swift*Command by MaxDesiatov · Pull Reques...

This removes an existing point of confusion, where SwiftBuildTool that handles swift build CLI invocations could be misunderstood as something responsible for build tools in plugins. It becomes esp...

11:03 AM

@swift-5.10.1 package completion-tool generate-fish-script @swift-6.0.3 package completion-command generate-fish-script

norio_nomura

@swift-5.10.1 package completion-tool generate-fish-script @swift-6.0.3 package completion-command generate-fish-script

# A function which filters options which starts with "-" from $argv. function _swift_swift_preprocessor set -l results

stdout.log

90.3 KB

norio_nomura

@swift-5.10.1 package completion-tool generate-fish-script @swift-6.0.3 package completion-command generate-fish-script

# A function which filters options which starts with "-" from $argv. function _swift_swift_preprocessor set -l results

stdout.log

100.84 KB

おっと、これは意図して無さそう

型名からCLIのコマンドが生成されてるっぽい？

そうですね、本当はArgumentParserのconfigurationでcommandNameを指定しないといけないです。

11:12 AM

とりあえず。 https://github.com/apple/swift-package-manager/pull/7600

ありがとうございます。

6.0リリース前で良かった…

お〜　発見できてよかったですね

RxSwiftのSwiftPMから提供されている、RxSwift-Dynamicを利用したマルチモジュール構成のXcodeプロジェクトのリンクでこけてしまい… 解決法などご存知の方いらっしゃらないでしょうか？エラー内容は以下です

No such file or directory: '/Users/XXX/Library/Developer/Xcode/DerivedData/UIKitPlayground-drqizwqmrobvwngdzdetphhibhsl/Build/Products/Debug-iphonesimulator/PackageFrameworks/RxSwift-Dynamic.framework/RxSwift-Dynamic'

サンプルプロジェクト: https://github.com/dazy1030/UIKitPlayground/tree/rxswift-dynamic

GitHub - dazy1030/UIKitPlayground at rxswift-dynamic

Contribute to dazy1030/UIKitPlayground development by creating an account on GitHub.

SwiftPMのビルド壊れる問題、ファイルの追加を無視する症状は簡単に再現できたけど

12:16 AM

initの変更を無視してリンクエラーになる症状は意外と起きなくて困った

12:17 AM

手元のプロジェクトで試したら即発生したが

あ、できた！

12:30 AM

小さくしようとしたら再現しなくなって戻せなくなった・・

12:32 AM

あ、できた

12:32 AM

これかなり繊細だ

@Yuta Saito リビルド壊れる問題の再現パッケージ作ったんだけどswiftpm公式に投稿する前に、最低限自分以外の環境でも再現できるか確認したいので、↓をやってみてもらえませんか？ https://github.com/omochi/swift-deps-rebuild-bug $ git clone https://github.com/omochi/swift-deps-rebuild-bug $ cd swift-deps-rebuild-bug $ ./repro.bash ↑のステップを実行して、最後にリンクエラーが出れば再現成功

GitHub - omochi/swift-deps-rebuild-bug: The Swift build system enco...

The Swift build system encounters link errors instead of rebuilding when using local packages - omochi/swift-deps-rebuild-bug

+ pwd /home/katei/ghq/github.com/omochi/swift-deps-rebuild-bug + cd AppPackage + swift package clean + swift build Building for debugging... [30/30] Linking app Build complete! (3.71s) + cd .. + cd ToyboxPackage/Sources/ToyboxCore + sed 's/a: Int = 0/a: Int = 0, b: Int = 0/' Debug.swift + mv -f Debug.2.swift Debug.swift + cd ../../../AppPackage + swift build Building for debugging... error: link command failed with exit code 1 (use -v to see invocation) /home/katei/ghq/github.com/omochi/swift-deps-rebuild-bug/AppPackage/Sources/AppModule/App.swift:9: error: undefined reference to '$s10ToyboxCore8toyDebug1aySi_tF' clang: error: linker command failed with exit code 1 (use -v to see invocation) [14/16] Linking codegen

12:49 AM

$ swiftc --version Swift version 6.0-dev (LLVM 4e9ab6351de9f4d, Swift d1343dc55bac19f) Target: x86_64-unknown-linux-gnu

12:49 AM

再現してそう？

なんかうちと違うけどリンクエラーは出てるな。

[omochi@omochi-mbp swift-deps-rebuild-bug (main =)]$ ./repro.bash + pwd /Users/omochi/github/omochi/swift-deps-rebuild-bug + cd AppPackage + swift package clean + swift build Building for debugging... [24/24] Applying app Build complete! (0.95s) + cd .. + cd ToyboxPackage/Sources/ToyboxCore + sed 's/a: Int = 0/a: Int = 0, b: Int = 0/' Debug.swift + mv -f Debug.2.swift Debug.swift + cd ../../../AppPackage + swift build Building for debugging... error: link command failed with exit code 1 (use -v to see invocation) Undefined symbols for architecture arm64: "ToyboxCore.toyDebug(a: Swift.Int) -> ()", referenced from: AppModule.App.main() -> () in App.swift.o ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) error: fatalError [9/14] Linking app

Linuxでためした

Linuxだからかな？

12:50 AM

まあいいか、むしろ2つの壊れがあるのは良いことだ

12:50 AM

READMEとか補強してから投稿する

12:51 AM

確認ありがとう

再現できれば直ったも同然

２年前ぐらいからずっと困ってたのでアツい

12:55 AM

実務環境だとこれが発生すると $ swift package clean しないといけなくて、その結果3000ファイル以上のリビルドが発生するのでツイッターが捗ってしまう

投稿した https://github.com/swiftlang/swift-package-manager/issues/7715

The Swift build system can sometimes skip necessary rebuilds and re...

Is it reproducible with SwiftPM command-line tools: swift build, swift test, swift package etc? Confirmed reproduction steps with SwiftPM CLI. The description text must include reproduction steps w...

あざす

bashで動くスクリプトに.bashとつけてるところで変に感心してしまった。

$ ./repro.bash + pwd /Users/norio/ghq/github.com/omochi/swift-deps-rebuild-bug + swift package --package-path AppPackage clean + swift build --package-path AppPackage Building for debugging... [24/24] Applying codegen Build complete! (0.84s) + sed -i -e 's/a: Int = 0/a: Int = 0, b: Int = 0/' ToyboxPackage/Sources/ToyboxCore/Debug.swift + swift build --package-path AppPackage Building for debugging... error: link command failed with exit code 1 (use -v to see invocation) Undefined symbols for architecture arm64: "ToyboxCore.toyDebug(a: Swift.Int) -> ()", referenced from: AppModule.App.main() -> () in App.swift.o ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) error: fatalError [10/14] Linking codegen

お、同じ挙動だ、確認ありがとうございます

1:22 AM

--package-path が出てるところがちょっと違うな？

あ、repro.bash書き換えました。

ああなるほど。cdしないようにしたのか。

cdしないほうがログに出たコマンドをコピペしやすくて便利

その方がステートレスでいいですね。

1:26 AM

sed -i -e が mac と linux で互換にならないって話があって、mv使った2手で置換してるところがcdしたいな・・・(136点の回答) https://stackoverflow.com/questions/5694228/sed-in-place-flag-that-works-both-on-mac-bsd-and-linux (edited)

sed in-place flag that works both on Mac (BSD) and Linux

Is there an invocation of sed todo in-place editing without backups that works both on Linux and Mac? While the BSD sed shipped with OS X seems to need sed -i '' …, the GNU sed Linux distributions

ここで作業中 https://github.com/kateinoigakukun/swift-deps-rebuild-bug

あ〜　置換するんじゃなくて最初から置いとけばいいのか〜〜 (Debug.step1|2.swift を見た) (edited)

ふむ

TARGET=ToyboxPackage/Sources/ToyboxCore/Debug.swift sed 's/a: Int = 0/a: Int = 0, b: Int = 0/' $TARGET | (sleep 1; tee $TARGET >/dev/null)

(edited)

kateiアップデートでsedを使わないスタイルにしていて、これが良さそうですね。

ToyboxModuleでToyboxCoreへの依存が間接化されてるのがミソっぽい

そうかも。その辺いじってたらできた。ToyboxCoreを直接参照すると大丈夫な気がする。

Package.swift上で直接dependenciesに記述されてないモジュールをimplicitな依存としてimportしてる状況: A -> B -> Cの依存関係で A -> Cのエッジが明示的に記述されてないがAがCをimportするで、Cにソースレベル上互換だけどABI上非五感な変更があると、AとBのソースを変更する必要がないのでAもBのオブジェクトファイルが作り直されない、というストーリーだ

2:09 AM

完全に理解した

・・・ローカルパッケージって関係ない？

関係ないような気がする

でも経験的には、AppPackageの中で何をやっても大丈夫で、ToyboxPackageの中の変更だけ問題が起きるんだよね

2:12 AM

なんだろなー

ローカルパッケージなしで再現できた https://github.com/kateinoigakukun/swift-deps-rebuild-bug/commit/cb8a219b01e87a4e40c6e5b5ab676a7009340bc2

マジかｗ

そしてこれは --experimental-explicit-module-build で検出できる問題だな

2:19 AM

experimental-explicit-module-buildモードではimplicitな依存エッジを明示的にエラーにするので

2:20 AM

今回の場合だとこういうエラーとして報告してくれる

/home/katei/ghq/github.com/omochi/swift-deps-rebuild-bug/AppPackage/Sources/AppModule/App.swift:1:8: error: no such module 'ToyboxCore' 1 | import ToyboxCore | `- error: no such module 'ToyboxCore' 2 | 3 | public struct App {

そんなモードが検討されてるの？間接依存めっちゃ使ってるから、書き下しまくることになってヤバそうだ

今回のXcode 16にもインテグレートされてていまはオプトインだけどそのうちデフォルトにするんではないかな

2:22 AM

https://forums.swift.org/t/explicit-module-builds-the-new-swift-driver-and-swiftpm/36990

Explicit Module Builds, the new Swift Driver, and SwiftPM

Hi all, In the llbuild2 announcement, @ddunbar mentioned the goal of supporting "explicit modules" in the build system. I wanted to describe what explicit modules are, why they are important, and the developer work we're doing to bring the benefits of explicit module builds to SwiftPM. Modules in Swift Swift programs are composed of a number ...

2:22 AM

https://developer.apple.com/documentation/xcode/building-your-project-with-explicit-module-dependencies

Building your project with explicit module dependencies | Apple Dev...

Reduce compile times by eliminating unnecessary module variants using the Xcode build system.

swift-collections とか import Collections することで import SortedCollections とか省略するようになってるけど

2:22 AM

こういうのはどうなるんだ？

それは@_exported だったりしませんか？

#if !COLLECTIONS_SINGLE_MODULE @_exported import BitCollections @_exported import DequeModule @_exported import HashTreeCollections @_exported import HeapModule @_exported import OrderedCollections // Note: _RopeModule is very intentionally not reexported, as its contents // aren't part of this package's stable API surface (yet). #endif

Sources/Collections/Collections.swift

2:23 AM

そうなってるね

それは多分OK

@_exported 使わないと実用性が保てなさそうだ

2:24 AM

逆に exported を使ってたら問題は起きないの？

2:24 AM

これもパッケージグラフでは間接モジュールなのは変わってなくて、ソースコード上でimportを自動で間接化してるだけだから、むしろ問題設定は難しくなってそうだけど。今の再現環境では A に少なくとも import C ってソースで書いてあるけど、それも無くなってしまう。 (edited)

Yuta Saito

https://developer.apple.com/documentation/xcode/building-your-project-with-explicit-module-dependencies

ふむふむ

どうなんだろう。こういうreexportするのそこまで多くないと思うんですけどねー

Yuta Saito

Package.swift上で直接dependenciesに記述されてないモジュールをimplicitな依存としてimportしてる状況: A -> B -> Cの依存関係で A -> Cのエッジが明示的に記述されてないがAがCをimportするで、Cにソースレベル上互換だけどABI上非五感な変更があると、AとBのソースを変更する必要がないのでAもBのオブジェクトファイルが作り直されない、というストーリーだ

このストーリーだと Bがなくて A -> C だけの世界でも、同じことになりそうだけど↓

Cにソースレベル上互換だけどABI上非五感な変更があると、AとBのソースを変更する必要がない

2:29 AM

本質的にソース互換性だけ追跡してもおかしくないか、ビルドシステムとしてはABI互換性を常に考えないといけないはずだ (edited)

そのシナリオだとAはC.swiftmoduleに依存するのでAはリビルドされます

2:30 AM

A -> B -> CだとB.swiftmoduleはC.swiftmoduleに依存するんだけど、 (edited)

2:31 AM

その結果 B.swiftmoduleのコンテンツ内容が1バイトも変わらないので

2:31 AM

Aはリビルドされない

あ〜なるほど。swiftmoduleへの依存としてビルド依存グラフは組まれているからバイナリは考慮しているけど

2:32 AM

バイナリの先のバイナリの変更が伝播しないのか

2:32 AM

実際にリンクすることを考えるとそのシナリオにおいても A -> C.swiftmodule の依存が設定されないといけない？

えーと

2:33 AM

A.o -> C.swiftmoduleの依存が無いことが問題で

explicit module buildでユーザに手でやらせようとしてることをswiftpmがやってくれたらいいのでは

implicitな依存を許容すると

2:34 AM

本当はAがCにインターフェースレベルで依存してない場合でもCの変更によってAをビルドし直しになるのでは

まさにそれをコンパイル時の意味解決の結果で精密にやってくれる仕組みがあるものだと思ってたｗ

2:35 AM

再現の例だと toyDebug 関数を呼び出してるからビルドしなおしが必要だけど

2:35 AM

そういうのがなかったらいらない

2:36 AM

確かに間接的な依存をただ伝搬させて集めるだけだと無駄なリビルドが起きやすくなっちゃうのか (edited)

Explicit Module buildの最初のdep scanフェーズは

2:38 AM

swiftinterfaceとかClang Module headerとか

この問題はビルドシステムの実装のバグやミスではなくて、意図があって作られた設計が、特定の状況でうまくいかないって話なのかな、思ったより深いか (edited)

のレベルでしかスキャンしないので、そこに出てこない internal importに関しては感知しない

2:39 AM

ような気がしたが普通の importステートメントはswiftinterfaceに出てくる気もしてきた

1

internal importなるほど

これ意図的かわからんなー

意図してなかったバグであって欲しいｗ

Hmm スキャナ自体はAのビルドに対してCの依存を報告してるな〜

おっ

swift-frontend -scan-dependenciesコマンド経由とlibSwiftScan.so経由で出てくる依存グラフが違う。。

libSwiftScanに含まれてないfrontend固有の処理があるんか

そこは一致しててその後のpost processingでAからCのエッジが消えてるな

おお

3:51 AM

核心に近づいてそう

これが

 { "swift": "AppModule" }, { "modulePath": "AppModule.swiftmodule", "sourceFiles": [ "/home/katei/ghq/github.com/omochi/swift-deps-rebuild-bug/AppPackage/Sources/AppModule/App.swift" ], "directDependencies": [ { "swiftPrebuiltExternal": "Swift" }, { "swiftPrebuiltExternal": "SwiftOnoneSupport" }, { "swiftPrebuiltExternal": "_Concurrency" }, { "clang": "_SwiftConcurrencyShims" }, { "swiftPrebuiltExternal": "_StringProcessing" }, { "swiftPrebuiltExternal": "ToyboxCore" } ], "details": { "swift": { "commandLine": [ ], "contextHash": "PAYFYPM8H050", "isFramework": false, "extraPcmArgs": [ "-Xcc", "-target", "-Xcc", "x86_64-unknown-linux-gnu", "-Xcc", "-fapinotes-swift-version=5" ] } } },

3:58 AM

こうなってしまう

 { "swift" : "AppModule" }, { "details" : { "swift" : { "extraPcmArgs" : [ "-Xcc", "-target", "-Xcc", "x86_64-unknown-linux-gnu", "-Xcc", "-fapinotes-swift-version=5" ], "isFramework" : false, "commandLine" : [ ], "contextHash" : "3BE0ZWLHZZ6AY" } }, "modulePath" : "AppModule.swiftmodule", "directDependencies" : [ { "swiftPrebuiltExternal" : "Swift" }, { "swiftPrebuiltExternal" : "SwiftOnoneSupport" }, { "swiftPrebuiltExternal" : "_Concurrency" }, { "clang" : "_SwiftConcurrencyShims" }, { "swiftPrebuiltExternal" : "_StringProcessing" } ], "sourceFiles" : [ "\/home\/katei\/ghq\/github.com\/omochi\/swift-deps-rebuild-bug\/AppPackage\/Sources\/AppModule\/App.swift" ] },

4:06 AM

変わってる？

ToyboxCore

あ、一個消えてる (edited)

4:07 AM

もしかしてローカルパッケージのこと忘れてて、知らない名前になってサニタイズ的に消してない？ｗ (edited)

うーんローカルパッケージ辞めたしなぁ

そうでした。

わからんなー完全に同じfrontendコマンドを実行してるはずなのにswift-driver経由と素のfrontend実行で出力が変わるように見える

4:11 AM

いや！わかったぞ

4:12 AM

.build/debug/Modules にToyboxCore.swiftmoduleが残ってるか否かで変わってるんだ

4:13 AM

あー、だからdependency scanするのにも順番が重要なんだ

ビルドディレクトリの中間ファイルの有無が影響して変化してるのか (edited)

4:15 AM

それでコマンドが同じなのに挙動が変わるのね

あれ、そもそも --experimental-explicit-module-build で全然ビルドできないな

4:32 AM

explicit-module-build無しのケースでこの問題を直すことは可能なんだけど、そもそもこれは直して良いのかがわからないんだよなー

cleanしたらビルドできる状況で、ビルド失敗するのは振る舞いとして変じゃないすか？

4:33 AM

キャッシュ機構がバグってるだけ (edited)

4:34 AM

ビルドシステムはキャッシュがちゃんと利用できる場合にだけインクリメンタルビルドしてほしい (edited)

いやぁ成功するのがたまたまというか

まあでもかといって、この場合はフルビルドされても嬉しくないけど・・・ (edited)

そもそもAからCをimportできるのがたまたま。

Yuta Saito

そもそもAからCをimportできるのがたまたま。

えーっ！何年も当然できる事と思ってた

4:37 AM

野良でもそれに依存してないのかなあ

4:39 AM

仮にその挙動が不正なんだったとした場合、同じ構成をexported importで組んだ場合は問題は起きないの？

4:40 AM

つまり、A->Bはパッケージ定義もあるし、importもするけど、Aの中にCのimportは書かない(Bに書いたexported importを使う)

4:41 AM

もしこれでもダメな場合、swift-collectionsのREADMEとか間違いが書いてあった事になる

Xcodeは成功してしまいがちだけど、SwiftPMだと暗黙孫モジュールインポートはちょいちょい問題になってません？

ちょいちょい問題になるのは、グラフが辿れないのにビルドできるパターンだと思ってた

4:46 AM

A->B->Cの接続のどちらかがそもそも書かれてなくても、Xcodeだといけるがち

グラフ自体は毎回辿れてたような気がします

4:48 AM

ちょっと刺激を与えると直るからあまり記憶に残ってないな

incrementalビルドするやつで@_exported 使っちゃだめですよ

そうなんか

4:50 AM

swift-collectionsみたいにパッケージの中に閉じてればいいって事？

swift-collectionの開発時には問題になると思う

な、なるほど

あとバージョンのアップデートでも壊れると思う

4:53 AM

SwiftPMのビルドシステムに乗らないやつならOK

パッケージの中で細かくターゲット切ってるからちゃんと書き下すのはめんどくさそうだなあ

少なくともビルドシステムがサポートしてないインポートが書かれてた時にそれをユーザに伝える術がないのがまずいすね

そうですね、実は壊れてて突然問題が起きる、というのは困るし、何が悪いかわからないから直せない

explicit module buildで解決するやつだと思ったけど少なくとも今壊れてて試せない状況だった

なるほど

5:21 AM

Explicit Module Builds Explicit module builds are an attempt to move the compilation of textual modules into binary modules out of the Swift compiler instance that imports the module, and up into the build system as an explicit compilation step.

5:22 AM

テキストモジュールをバイナリモジュールに変換するプロセスを、(従来暗黙であった)コンパイラでの処理をするのをやめて、ビルドシステムにおける(明示的な)ステップの一つとする

5:23 AM

と書いてあるな孫依存の話はその後の「Fast Dependency Scanner」かな

5:24 AM

The output of the dependency scanner is a graph of all of the dependencies of that Swift module, included every module that will be imported (directly or indirectly).

コンパイラに依存スキャナモードが実装されたよ、直接や間接を列挙するよ、と言ってそう

5:25 AM

explicit module buildは依存対象を(孫依存を禁じて)explicitに宣言するスタイルにするものかと思ったけど違う？ (edited)

explicitな依存の記述の話ではないです

1

.build/debug/Modules にToyboxCore.swiftmoduleが残ってるか否かで変わってるんだあー、だからdependency scanするのにも順番が重要なんだ

↑ああ、まさにこの swiftmodule ファイルを作るところが、レースコンディションになっているという話なのか

コンパイラフロントエンドプロセスの中でimplicitにビルドされてたimported moduleのインターフェースコンパイルを明示的にビルドシステムのジョブにするという話

5:27 AM

そう

https://discord.com/channels/291054398077927425/561853152408895518/1270932377845104712 #swift-syntax からこっちへ移動モックテストを書いて、swiftLanguageVersions: [.v5, .version("6")]が書かれた外部パッケージはPackage.swiftのswift-tools-versionに関係なく-swift-version 6でビルドされることを確認した。この挙動はバグってことで良いのかな。

BuildPlanTests.patch

2.95 KB

testDefaultVersionsWithLanguageVersion.log

1.67 KB

なんか最近言及を見たな　どこだっけな (edited)

根本的な問題はSwift SDKに同梱されているコンパイラのバージョンをSwiftPMが認識していないことではないですかね

Swift SDK使わなくても起きるので。

https://github.com/swiftlang/swift-evolution/blob/b3d79afbe083a770c79f328bb40d4834e941f163/proposals/0209-package-manager-swift-lang-version-update.md

swift-evolution/proposals/0209-package-manager-swift-lang-version-u...

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swiftlang/swift-evolution

6:43 AM

おお、swift-tools-version優先するってことになってるんだ

Example 4 の例は、tools-versionが versions宣言をキャップすることを言ってると思う

6:44 AM

Example 3 も同じことを言っている

swiftLanguageVersionsにswift-tools-versionより大きいバージョンを設定できる意義ってのは何？

6:46 AM

コマンドラインオプションでオーバーライドできる的な感じなのかな？

The custom version string will be passed as-is to the value of -swift-version flag. The custom version string allows a package to support and make use of new language versions which are not known to the manifest API of the current tools version. This is important for packages which want to add support for a newer Swift language version but also want to retain compatibility with an older language and tools version, where the new language version isn't known in the manifest API.

6:48 AM

対応はしてるってことを宣言するためって書いてある？

6:49 AM

バージョンを自動決定する時には swift-tools-version を見るというだけで、ビルド起点側で強制的に指定することができるってことかな？ (edited)

6:49 AM

というか、ルートパッケージで決まるのかな。

6:49 AM

依存される側のライブラリの swift-tools-version は無視されるんじゃないだろうか (edited)

テストでは依存してる側のswift-tools-versionも無視されてます。

norio_nomura

テストでは依存してる側のswift-tools-versionも無視されてます。

それは間違ってそうですね。ターゲットごとにversionが5とか6とか混在できるようになる改修とかのタイミングで壊れちゃったんじゃないだろうか

https://github.com/swiftlang/swift-package-manager/blob/392a2a99510f391cb172ceef510d7aefce5c7c62/Sources/PackageLoading/PackageBuilder.swift#L1269-L1276 ここでtools-versionよりもswiftLanguageVersionsを優先してる。

swift-package-manager/Sources/PackageLoading/PackageBuilder.swift a...

The Package Manager for the Swift Programming Language - swiftlang/swift-package-manager

7:38 AM

 // Figure out the swift version from declared list in the manifest. let declaredSwiftVersions = try declaredSwiftVersions() let computedSwiftVersion: SwiftLanguageVersion = if let declaredSwiftVersion = declaredSwiftVersions.first { declaredSwiftVersion } else { // Otherwise, use the version depending on the manifest version. self.manifest.toolsVersion.swiftLanguageVersion }

これって、swiftLanguageVersionsを参照する必要ない気がする。

swiftLanguageVersionsにtools-versionより古いバージョンが書かれている場合を考えると、ここのキャップが ToolsVersion.current ではなく self.manifest.toolsVersion.swiftLanguageVersion になってるべき？ https://github.com/swiftlang/swift-package-manager/blob/392a2a99510f391cb172ceef510d7aefce5c7c62/Sources/PackageLoading/PackageBuilder.swift#L1248

そういう実装ミスなのか。でも swift-tools-version に基づいて実行するツールバーションが決まってるんじゃないんか。

swift-tools-version:6でswiftLangaugeVersions: [.v5]の時に、-swift-version 5としたいかどうかによる？ (edited)

SE-0209はそのケース明示してないんですねー

ここのキャップが ToolsVersion.current ではなく self.manifest.toolsVersion.swiftLanguageVersion になってるべき？

互換性を考えると、これが良さそう。

8:19 AM

なんかmainブランチでビルドとか通らなくて、色々めんどい

8:22 AM

こんな感じか。

PackageBuilder.patch

1.11 KB

良さそうに見える

全く困っていないのに、なぜこんなことを調べてしまったのか…

1

そこに壊れたSwiftPMがあるから…

2

キャップのコードは、// swift-tools-version:導入前からのコードぽい。 https://github.com/swiftlang/swift-package-manager/commit/c946f313e5ba5f96ebbed3e424befe45d41a2c8e#diff-68f661bfe880d4bf7059718964ee104add3839e7e2f5bc8bfd644ab706ff7149R812

Update tools version to 4.0 · swiftlang/swift-package-manager@c946f31

-- Update SwiftPM version to 4 and pass -swift-version flag to compiler

9:00 AM

PR書きたくなさすぎて、どうでもいいこと調べてしまう…

1

norio_nomura

こんな感じか。

これPR書いたとしても、思い切りbreaking changeな気がする。

というか、SE-0209通りに動いてないのはその通りなのだけど、今の挙動の方が正しい気がする。

そういうこともありますよね。プロポーザルの修正が出るやつ。

issue書いた https://github.com/swiftlang/swift-package-manager/issues/7869 (edited)

1

返事きた。

The actual design states: The package manager will use standard version numbering rules to determine precedence of language versions. For e.g. 5 > 4.2.1 > 4.2 > 4. ... When building a package, we will always select the Swift language version that is most close to (but not exceeding) a valid language version of the Swift compiler in use. If a package does not specify a Swift language version, the tools version of the manifest will be used to derive the value.

まあ、例だけを見ずに本文をちゃんと読め、って事だね。 (edited)

https://github.com/swiftlang/swift-package-manager/blob/da65429043cb0a5151bdd5e9666df770dfbc72a5/Sources/PackageDescription/SupportedPlatforms.swift#L374

swift-package-manager/Sources/PackageDescription/SupportedPlatforms...

The Package Manager for the Swift Programming Language - swiftlang/swift-package-manager

8:30 AM

手元のXcodeだと .v15 が書けるけど Linux 版だと書けない

8:30 AM

mainブランチでも実際書いてない

8:30 AM

どうなってんや

ありゃ、アップストリームし忘れ？

8:31 AM

とりあえず .macOS("15.0") でお茶を濁して (edited)

1

Yuta Saito

ありゃ、アップストリームし忘れ？

release/6.0.1 ブランチでも書いてないんだよね　どこにいるんだろ

Filed https://github.com/swiftlang/swift-package-manager/issues/7968

2

1

tools-versionを6.0にしたらSotoCoreのシンボルがリンクできなくなった

9:16 AM

Soto code generatorが壊れるとかあるのかなそもそもSotoCoreは生成対象じゃないしなあ

リンクフェーズの壊れ？

はい

9:23 AM

Xcode16にするだけなら問題なかったのにswift-tools-versionを6.0にしたら壊れた？ような気がする他の変更もちょっとやっててまだ絞りきれてないけど

9:23 AM

そこがリンクフェーズに影響与える事あるんかしら？

9:23 AM

soto code genratorが作るSotoターゲットのビルド時間もめっちゃ伸びた気がする

ビルドプランのキャッシュがおかしくなることはあると思うんですけど、キャシュ消してもだめですか？

いろいろ消したりはして何周かやった

9:25 AM

.buildとDerivedData

なるほど。とすると、これ以上は症状見ないとわからないや

1

これから夜の家事育児なのでまた明日他にも試してみます

どもども

それとは別に言語モードを6にしたらビルドプロセスがクラッシュしまくって、スタックトレースも出なくて破滅してたのも気になるがこれはまた後日・・・

わはは

swift-tools-versionは関係なかった

10:57 AM

platformを .macOS(.v15) にすると問題が起きることがわかった

10:58 AM

めっちゃ謎だ。

Yuta Saito

Filed https://github.com/swiftlang/swift-package-manager/issues/7968

とりあえずこっちはmainで治った https://github.com/swiftlang/swift-package-manager/pull/7969

やったあ。サーバーはスナップショットでいいから使える。でも Xcode側でこれ使うだけでリンク壊れる問題が邪魔だ、、、これ再現取るの難しそうだ

再現とれた！ｗ

12:44 AM

お

12:44 AM

Xcodeじゃなくても死ねるぞ

む

12:56 AM

同梱されてるswiftpmのバージョンが Swift 6.0.0-dev だ。devがついてる。

12:58 AM

https://github.com/swiftlang/swift-package-manager/issues/7987

The build fails when setting the support platform to macOS 15 · Iss...

Is it reproducible with SwiftPM command-line tools: swift build, swift test, swift package etc? Confirmed reproduction steps with SwiftPM CLI. The description text must include reproduction steps w...

12:58 AM

報告した

12:58 AM

これは直ってほしい・・・

1:00 AM

これが解決しないとターゲットをmacOS15にできなくて、それができないとMutexが使えない。Mutexが使いたい。

https://github.com/swiftlang/swift/issues/76690

Swift 6 misplaces witness tables when compiling against macOS 15 · ...

Description When compiling a package that uses ConsoleKitTerminal from console-kit to set up the LoggingSystem from swift-log, Swift 6 seems to misplace the protocol witness tables for LoggerFragme...

1:07 AM

仲間が居た

1:07 AM

コード生成は関係なかったのかな。

しばらくセコイア行きは控えよう・・・

platforms: [ .macOS(.v15), ], にしなければ、OSアプデは問題ないすよ (edited)

ここで分岐するんですね

そうなんだよね　謎だ

1:20 AM

v14ターゲットの時は問題が起きない

SwiftPMって、Swiftの実装をObjCから使うことってできないんでしょうかね？

あ、ObjCからは使えるみたいですね

7:29 AM

ObjC++からは使えない・・・？

SwiftのC++ interop機能は両方向だけど、そっちをswiftpmでやってみたことはないな

https://www.swift.org/documentation/cxx-interop/project-build-setup/#:~:text=Swift%20Package%20Manager%20does%20not%20yet%20provide%20support%20forusing%20Swift%20APIs%20in%20C++.