Xcodeの操作忘れてた。Growlの入れ込み。 [プログラミング]
改造中メールチェッカー、mailpeeper-tlsはOpenSSLを入れているので、Xcodeの範囲外から入れております。なので、普通にリンクしても特定の場所に置かないとダメなのでした。それはdylibでも、外から取り入れるフレームワークでも同じ事らしく、システムに入れ込んだもの以外は、自分で取り入れないとダメという事になっています。
WindowsのDLLなら、呼び出すexeと同じディレクトリに入れるか、ライブラリのパスが通っている場所に置けばいいだけです。でもMacだと少々面倒臭いことをしなくてはなりません。.dylibの場合はinstall_name_toolで何とかして、ターゲットのスクリプトを実行のところで、MacOSディレクトリにcpでぶち込んであげないといけないのでした。ちなみに設定を相対ディレクトリで指定してあげて、別のディレクトリに指定してあげる事も可能です。
今回、Growl.flameworkを入れるわけなんだけど、勿論、システム外のフレームワークなぞ使った事はない。前にGrowlのページを見た時に、Xcodeでの扱い方を見た気がする。ということで、今からGrowlのページへ行く。英語読むの面倒いなぁ。
http://growl.info/documentation/developer/implementing-growl.php
んと、「既存のフレームワーク」とか選んだけではダメみたい。リンクとかはされているようなんだけど、実物のフレームワークがどこかにないとダメなので、結局、実行される.appのバンドル内に、Growl.frameworkをコピーして入れないといけない。
結局、ターゲットのところを右クリックして、「追加＞新規ビルドフェイズ＞新規コピーファイル」と選んでいくと、ダイアログが立ち上がってきて、Xcodeのターゲットの項目の下に「ファイルをコピー」という項目ができる。
そこに既存のフレームワークで選んだGrowl.frameworkをドラッグして持ってくると、エラーで止まらずに実行できるようになる。ファイルのコピーを行なわないと、デバッグですぐに止まっちゃうんですよね。
というわけで、インプリしないでフレームワークを入れる事はできました。今度は実装の出番。
これを入れ込めば使えますぜ、って事かな。
やってみる。なんか新規作成などの適当なアプリに、ボタンだけ付けて動くかどうか実験したいです。いきなり埋め込んで面倒なことが起こんなきゃいいんだけど。
あ、git addってディレクトリを指定すると、サブディレクトリとかも全部入れてくれるのね。特に再帰的なパラメーターは必要ありませんでした。ちょっと分からなくて確認のために、コミットしてみたらきちんと入っていたので問題ないっす。そんなわけで、Growl.frameworkがgitのリポジトリに入ったのでした。
サンプルソースが無くて、正直苦労しましたが、GrowlMailのソースアーカイブの中にいくつか入っているのを見つけました。
http://growl.info/growlmail/
http://growl.cachefly.net/GrowlMail-1.2.4-src.tbz
なんかMacの標準アーカイバじゃ開けなかったので、StuffItで解凍しました。多分、コマンドラインでも解凍できそうだけど、そこまで意固地じゃないのでユルい方に流される事にした。にしても、サンプルソースはSDKとかに入れておいてほしいのだが。あんまり親切じゃないな。ソースが無くて何とかなるようなものじゃないし。ドキュメントも案外適当に作られていて、かなり酷いものではあった。
何か酷い。何がヒドいのかと言うと、Xcodeの作りが悲惨だ。別の二つのプロジェクトを開いて、デバッグモードでステップ実行とかやってると、間違ってブレークポイントが共有されてしまったりしていて、今日のプログラミング的にあり得ない感じ。妙なところでブレーポイントが止まるなぁと思ってたら、別のプロジェクトから設定が混入して酷い有様に。今時信じられんバグだ。
というか、アンタ達（Xcodeなどのツール）、他のプロセスで動いてるんじゃないのかよ、とツッコミを入れたくなった。恐らく旧来の似非マルチタスクで満足していた酷いプログラマが残っているとしか思えないんだが。折角地盤がUNIXで堅いのに、アプリケーションでユルくしたら同じでしょうが。
そういった意味で「⌘+tab」で切り替えられる単位が、アプリケーション単位で、プロセス単位であるという事からも、アップルの考えってその程度なのか、と考えさせられる。そんな近代的なOSってのはMac以外に存在しないだろう。誠に残念な次第だ。開発環境ぐらい、同アプリケーションでもプロセス単位できっちりメモリ管理してほしいものだ。どうせメモリをケチるようなOSじゃないから、つまらない共用とかは今すぐやめてほしい。いちいち、プロジェクトごとにXcodeを開き直すの面倒なんですけど…。愚かな事甚だしい。折角こっちはメモリをたくさん積んで、
わー、他のプロジェクトのファイルが別のプロジェクトで開けちゃってるよ。意味分かんない。タダで配っているから手を抜いて作っていいなんて理屈はどこにもないんだからねっ（ツンデレ風に）。次回はGrowlのサンプルソースを見ていく。
WindowsのDLLなら、呼び出すexeと同じディレクトリに入れるか、ライブラリのパスが通っている場所に置けばいいだけです。でもMacだと少々面倒臭いことをしなくてはなりません。.dylibの場合はinstall_name_toolで何とかして、ターゲットのスクリプトを実行のところで、MacOSディレクトリにcpでぶち込んであげないといけないのでした。ちなみに設定を相対ディレクトリで指定してあげて、別のディレクトリに指定してあげる事も可能です。
今回、Growl.flameworkを入れるわけなんだけど、勿論、システム外のフレームワークなぞ使った事はない。前にGrowlのページを見た時に、Xcodeでの扱い方を見た気がする。ということで、今からGrowlのページへ行く。英語読むの面倒いなぁ。
http://growl.info/documentation/developer/implementing-growl.php
Note: Inclusion of Growl.framework in your application is required. 1. Download the frameworks from the Downloads page from there. 2. Copy the Growl framework to your application's project folder (or any subdirectory of it). 3. Add the Growl framework to your project, making sure that all the relevant target checkboxes are checked. The header files in the framework use UTF-8 encoding. 4. Add a Copy Files phase to your application's target. 5. Get Info on the Copy Files phase. 6. Set the destination to “Frameworks”, with no subpath (clear the field). 7. Drag the framework from the group tree into the Copy Files phase.
んと、「既存のフレームワーク」とか選んだけではダメみたい。リンクとかはされているようなんだけど、実物のフレームワークがどこかにないとダメなので、結局、実行される.appのバンドル内に、Growl.frameworkをコピーして入れないといけない。
結局、ターゲットのところを右クリックして、「追加＞新規ビルドフェイズ＞新規コピーファイル」と選んでいくと、ダイアログが立ち上がってきて、Xcodeのターゲットの項目の下に「ファイルをコピー」という項目ができる。
そこに既存のフレームワークで選んだGrowl.frameworkをドラッグして持ってくると、エラーで止まらずに実行できるようになる。ファイルのコピーを行なわないと、デバッグですぐに止まっちゃうんですよね。
というわけで、インプリしないでフレームワークを入れる事はできました。今度は実装の出番。
これを入れ込めば使えますぜ、って事かな。
Using Cocoa, you can use the following code snipped to load the framework in your bundle:
NSBundle *myBundle = [NSBundle bundleForClass:[MyMainClass class]];
NSString *growlPath = [[myBundle privateFrameworksPath] stringByAppendingPathComponent: @"Growl.framework"];
NSBundle *growlBundle = [NSBundle bundleWithPath:growlPath];
if (growlBundle && [growlBundle load])
{ // Register ourselves as a Growl delegate
[GrowlApplicationBridge setGrowlDelegate:self];
} else {
NSLog(@"Could not load Growl.framework");
}
If your application targets Mac OS X 10.4 or higher, you can use @loader_path instead of loading the bundle dynamically.
やってみる。なんか新規作成などの適当なアプリに、ボタンだけ付けて動くかどうか実験したいです。いきなり埋め込んで面倒なことが起こんなきゃいいんだけど。
あ、git addってディレクトリを指定すると、サブディレクトリとかも全部入れてくれるのね。特に再帰的なパラメーターは必要ありませんでした。ちょっと分からなくて確認のために、コミットしてみたらきちんと入っていたので問題ないっす。そんなわけで、Growl.frameworkがgitのリポジトリに入ったのでした。
サンプルソースが無くて、正直苦労しましたが、GrowlMailのソースアーカイブの中にいくつか入っているのを見つけました。
http://growl.info/growlmail/
http://growl.cachefly.net/GrowlMail-1.2.4-src.tbz
なんかMacの標準アーカイバじゃ開けなかったので、StuffItで解凍しました。多分、コマンドラインでも解凍できそうだけど、そこまで意固地じゃないのでユルい方に流される事にした。にしても、サンプルソースはSDKとかに入れておいてほしいのだが。あんまり親切じゃないな。ソースが無くて何とかなるようなものじゃないし。ドキュメントも案外適当に作られていて、かなり酷いものではあった。
何か酷い。何がヒドいのかと言うと、Xcodeの作りが悲惨だ。別の二つのプロジェクトを開いて、デバッグモードでステップ実行とかやってると、間違ってブレークポイントが共有されてしまったりしていて、今日のプログラミング的にあり得ない感じ。妙なところでブレーポイントが止まるなぁと思ってたら、別のプロジェクトから設定が混入して酷い有様に。今時信じられんバグだ。
というか、アンタ達（Xcodeなどのツール）、他のプロセスで動いてるんじゃないのかよ、とツッコミを入れたくなった。恐らく旧来の似非マルチタスクで満足していた酷いプログラマが残っているとしか思えないんだが。折角地盤がUNIXで堅いのに、アプリケーションでユルくしたら同じでしょうが。
そういった意味で「⌘+tab」で切り替えられる単位が、アプリケーション単位で、プロセス単位であるという事からも、アップルの考えってその程度なのか、と考えさせられる。そんな近代的なOSってのはMac以外に存在しないだろう。誠に残念な次第だ。開発環境ぐらい、同アプリケーションでもプロセス単位できっちりメモリ管理してほしいものだ。どうせメモリをケチるようなOSじゃないから、つまらない共用とかは今すぐやめてほしい。いちいち、プロジェクトごとにXcodeを開き直すの面倒なんですけど…。愚かな事甚だしい。折角こっちはメモリをたくさん積んで、
わー、他のプロジェクトのファイルが別のプロジェクトで開けちゃってるよ。意味分かんない。タダで配っているから手を抜いて作っていいなんて理屈はどこにもないんだからねっ（ツンデレ風に）。次回はGrowlのサンプルソースを見ていく。
タグ：freesoft
コメント 0