gdbinitの場所をWorkspaceを起点として選べるようにする．
id:monamour555:20070219 の後，いろいろ考えたのだけれども，プロジェクトを起点とするのは，どうも筋が悪いような気がしてきた．
確かに"Main"タブではワークスペースを指定するので，その情報を貰ってくるという手はあるのだけれども．タブを跨いで情報をやり取りするのは，一覧性に欠ける．
また，同ターゲットの複数プロジェクトがあるとき，おそらくそれらのプロジェクトのgdbinitは全く同一か，少なくとも共有したい場合があるような気もしてきた．
つまり，ワークスペースを起点とする辺りが適当なのではないかと．
で，作ってみた．"Debugger"タブは，org.eclipse.cdt.debug.mi.internal.StandartGdbDebuggerPage にあるものを流用しているため，ついにCDTに手を入れざるを得なくなった．
作る側の勝手な事情だけれど，ちょっと痛い．本家のアップグレードを常に監視しなければいけなくなるので．最大の防御法は，パッチを本家に採用してもらうこと．結局，ローカルパッチを溜め込むより，本家に運用してもらったほうがコストが低い*1．そんなわけで，修正案は，既にEnhancementに登録済み．
コーディングに際しては，ブログインストールモンキーKの記述がとても役に立った*2．最初，External Toolsと同じ方針でResourceSelectionDialogを使おうと思っていたのだけれども，ElementTreeSelectionDialogのほうが明らかにcoolだ．Extenal Toolsの実装は筋違いだとさえ思う．
OpenOCDサポートはResourceSelectionDialogを使っているのだけれども，近日中に直そう．
External Toolsとの対比で言えば，Variablesサポートの有無がある．
External Toolsの場合は，Variablesが使える．例えば ${workspace_log:/foo/gdb.init} と入力できる．これも結構悩んだ末，Variablesサポートを切って，フルパスで返すようにした．PizzaFactory3のデバッガサポートに関しては，Variablesを後で展開するようにもできるけれども，PizzaFactory3上でホストのGDBも使いたいというケースでは，破綻する可能性がある．また，(ソースは失念したが)Variablesは，近い将来廃止か別のフレームワークに置換の方向と聞いたような気もしている．
さらに，正直に告白すると，これ以上CDT本体のソースを弄り回したくないということもある．
複数人で環境を共有しながら開発するときには，パスの抽象化はしておきたいところだけれども…現状より悪くなるということではないので，黙認．期を改めて再考することにする．
さて，feature patchを作成して，無償版サイト辺りに置くのは当然として…PizzaFactory3とは関係なく，便利と思う人は少なくない*3拡張なので，それなりの扱いをしてもよいのかもしれない．
