Tritonn: configure --enable-abortをやめて自動判別にすべきか

Tritonn 開発

すごく細かい話なんですが。というかここ最近ずっとBlogを書いていなかったけれども、また書きたくなってきた。しかも細かい話。備忘録的な。

Senna 1.1.4では、

  • "--enable-abort"でビルドされたらsen_index_set_abort_callbackがlibsennaに存在する
  • そうでなければsen_index_set_abort_callbackがlibsennaに存在しない

というのが成立しているので、Tritonn側はAC_CHECK_LIBで自動判別すべきかもと思い始めた。

「libsennaは"--enable-abort"でビルドしてるけどTritonnからの呼び出し時には使わない」とかっていうケースは考慮しなくてもOKじゃないかと。

Tritonnのconfigure時にAC_CHECK_LIBで自動判別すると以下のメリットがあると思う

  • Tritonnのconfigureオプションを増やさずに済む(シンプルなのは良いこと)
  • 「うっかり付け忘れ」「間違えて付ける」ことによる不整合が起きなくなる

一方デメリットは、

  • TritonnからはSennaの--enable-abortを使わないけど別のSennaクライアントからは使うパタンに対応できない
  • Tritonnビルド時のlibsenna.soは--enable-abort付きだったけど、後でlibsenna.soを入れ替えたときに--enable-abort無しになった場合、Tritonnが起動エラー

かなぁ。そもそもenable abortは必要な機能だと思うし、デメリットに該当するパタンに遭遇する確率ってほぼゼロなんじゃないかとも思い。

明日までに考えが変わらなければ自動判別にしてしまおう。


性格によるものなのか、こういう細かいところも割りと気になってしまいます。設定手段を増やせばユーザの選択肢は増えますが、その分学習コストも上がるしミスの発生確率も上がるし、最適解は何かなーといつも考えてます。

話は変わりますが、ライブラリのビルドオプションとかって皆さんはどうやって取得してるんでしょう。よく○○-cfgというコマンドがインストールされてビルドに必要な情報(-Iとか-Lとか)を取得できるようになっているパタンがありますが、SennaもMeCabもconfigureオプションは取れないような。