これを見ると、なにやらライブラリの組み込みが無視されたということが伺えます。 具体的にはmissing required architecture arm64 のところで、おそらくarm64 用のバイナリが見つからなかったためにライブラリが無視されたということのようでした。 原因 原因は警告メッセージのとおりで、今回の場合はビルドされたライブラリに適切なバイナリが存在しなかったために発生したエラーでした。 ライブラリの場合は複数のバイナリをビルドしてまとめられたりするようですけど、デバッグビルドの時には効率優先で、現在のアーキテクチャーだけのバイナリを作るようにBuild Settings で設定されているようです。 Xcode 6 ではこれが推奨設定のため、プロジェクト設定を自動で調整してもらうと、この設定が有効になってビルドに失敗する場合もあります。 対処方法 対処方法は簡単で、Bui
ここの Build only if .travis.yml is present は最初は無効に設定されていて、特に .travis.yml がない場合は既定の実装が使われるみたいな話をどこかで見ましたが、とりあえず Xcode の Swift プロジェクトについては .travis.yml を用意しないとテストが実行されない様子だったので、ここでの設定に限らず必ず用意することになりそうです。 ここでは環境変数も指定できるようになっているようです。また、同時ビルド数の設定については、Travis CI の無料プランでは同時に1つまでに限られているようなので、今回は設定する必要はなさそうでした。 Travis CI でのテスト内容を決定する Travis CI と GitHub との連携設定が完了したら、どのようなテスト実行するかをリポジトリで指定します。 .travis.yml ファイルを
全く同じメソッドが、複数のプロトコルから既定の実装として与えられている、要は「曖昧な実装になっている」ため、どれを呼び出したら良いのかがわからないということを主張しているのでしょう。 そしてこのとき面白いのが、構造体 Picture を両方のプロトコルに準拠させようとしているところで、不可思議な次のビルドエラーが発生します。 既定の実装だけしかないのに、なぜ両方から「準拠できていない」と指摘されているのか。 これを見させてもらった最初は「Protocol Extension ってまだまだ甘い実装なのかな」と思ってみたりもしたんですけど、それからゆっくり考えていたら、なんとなく Swift の気持ちが分かってきました。 エラーの理由は曖昧性 まず、そもそもの大事なポイントなのですが、既定の実装を extension で添えるに当たって、その機能のシグネチャを protocol に宣言しておく
あるアプリが別のアプリを呼び出す方法にURL スキームというものがあります。 たとえば Web サイトを開くときに "http://xxx.xxx.xx/f/p1.html?n1=v1&n2=v2" のような URL が使われますが、カスタム URL スキームを使うと、これのプロトコル("http")の部分に独自の文字列を指定して、外から自分のアプリを呼び出してもらえるようになります。 このとき、URL の後の "://" に続いて、ホスト名("xxx.xxx.xx")やパス("/f/p1.html")やクエリ("n1=v1&n2=v2")という形で受け取ることができます。 ホスト名以降をどのような書式にするかは自分のアプリの方で決めて、それを他のアプリのプログラマーに使ってもらう形になります。 カスタム URL スキームを登録する 自分のアプリ用の URL スキームを登録するには、自分の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く