[freewnn:00044] Re: what to do? / directory structure

[MOTOKI Sinichi <sin@XXXX>]

 元木@ITLです。はじめまして。

# なんで否定するようなことばかり書いてしまうのだろう > おのれ
# トータル的には大賛成なのでご容赦を。

In article <199908081805.DAA27297@pop1.ngy.3web.ne.jp>
    frkwtto@osk3.3web.ne.jp (Tatsuo Furukawa) writes:

|     - libwnn
|     - jserver/cserver/tserver/kserver
|     - uum
|     - 辞書ツール
|     - Xwnmo
|     - (辞書)

 パッケージとして細分化するのは大賛成なのですが、個人的には
 ソースレベルでここまでする必要もないかなと思っています。

 この辺の「ユーザが細かく取捨選択できるようにする」ってのは
 各ディストリビューションのパッケージシステム(rpm とか deb 
 とか ports とか)に任せて、ソース側としてはなるべく個別ビル
 ド が容易なように作成しておけばよいのではないかと思います。

# ソースからビルドする時に各ソースパッケージの依存関係を考え
# るのがイヤだからですけど ^^;

 (将来は別として)現状ではソースパッケージとしては以下のよう
 な分け方がいいかなと思います。

 o [jctk]server, libwnn, 辞書ツール
 o 辞書
 o Xwnmo
 o uum

| というような感じで分離します。こうすると、例えば辞書ツールだけバージョ
| ンアップした時に他の部分を配布しなくていいので管理も楽になります。また、
| libwnn のように全てに影響を与えるような重要なライブラリもバージョンアッ
| プが比較的楽にできます。
|
| そして、何よりも楽なのが、個々が独立して小さくなるので理解が容易になり、
| 開発もやりやすくなると思います。

# 以下、現状&私的妄想を根拠に書いているので....

 そうすると、同じ役割をするファイルが各アーカイブに分散して
 しまいませんか?

 一つのバグを潰すのに 2,3 つの同じ部分を修正するのは結構めん
 どくさいことになるような気がします。
 (たとえば現状の Xsi/Wnn/etc/ 部分, jlib, jutil, jserver か
 ら参照されてる ;_;)

# CVS の CVSROOT/modules 機能で頑張るとある程度解決できるの
# かな?

 とりあえず libwnn, 辞書ユーティリティ, [jckt]server は一緒
 にしておいた方がよいかと。

 その中でソースファイルの依存関係を慎重に見極めながら分離で
 きるところは分離するのが比較的スムーズに動くのではないかな
 と思います。

| # でも、jserver が libwnn のソースを include していて、しかもオプショ
| # ンを変えてコンパイルしているため、分離するのがすごく大変。

 ですね。

 分離とは別の話で automake の基本的な枠組の中では jserver/ 
 において ../etc/wnnerrmsg.c を参照して CFLAGS を変更し 
 wnnerrmsg.o を作るってのが(automake的には)めんどくさかった
 りします。(簡単な方法を知らないだけかも....)

# 他のものと CFLAGS等が同じなら libhogehoge.a とかにしてリン
# クすればいいので楽なのですが

 同じディレクトリ内にあるのならば

>bin_PROGRAMS = jserver
>jserver_SOURCES = dispatch.c error.c jikouho_d.c mknode1.c \
>		atojis.c do_dic_env.c fzk.c jishoop.c mknode2.c \
>		b_index.c do_dic_no.c get_kaiarea.c jishosub.c \
>		rd_jishoop.c bnsetu_kai.c do_env.c hinsi_list.c \
>		jmt0.c readfile.c daibn_kai.c do_filecom.c initjserv.c \
>		jserver_id.c renbn_kai.c de.c do_henkan.c jbiki.c \
>		kai_area.c sisheng.c de_vars.c do_henkan1.c jbiki_b.c \
>		malloc.c snd_rcv.c do_hindo_s.c jikouho.c \
>		mknode0.c w_string.c wnnerrmsg.c \
>               strings.c sstrings.c bdic.c dic_atojis.c \
>		gethinsi.c revdic.c hindo.c pwd.c bcopy.c msg.c \
>		xutoj.c
>
>INCLUDES = -I$(top_srcdir)/Wnn/include
>CPPFLAGS = -DJSERVER -DWRITE_CHECK -D$(wnn_language) \
>	-DLIBDIR=\"$(wnnlibdir)\" \
>	-DSERVER_INIT_FILE=\"/$(wnn_server_init_file)\" \
>	-DHINSIDATA_FILE=\"/$(wnn_hinsidata_file)\"

 と Makefile.am に書くだけで make all でコンパイルして make
 install で $(bindir) にインストールする Makefile.in を作っ
 てくれます。

# しかし、同一ディレクトリでの他のサーバのビルドができない ;_;)
# 個々 configure するしかないのかなぁ

| 元木さん> 次に、cWnn(tWnn), kWnn も手を入れようかなと思ったのですが、 
| 元木さん> 今のソース構成だと automake(autoconf) にはあまり向かなそう 
| 元木さん> なので、(ちょっとやってみた感触として)そこそこ大変だと思わ 
| 元木さん> れます。
|
| というわけで、FreeWnn 1.2 では automake の都合のいいようなディレクトリ
| 構成で進めていきましょう!

 個人的には automake 大好き人間なので全然異論は無いのですが...
 いろいろ問題点もあると思います。

| 元木さん> 元木的には [ctk]Wnn と 日本語Wnn のコンパイルの段階での違い 
| 元木さん> は辞書や[ctk]serverrcなどのインストールするファイルと -D の 
| 元木さん> 違いぐらいと思っているので [ctk]Wnn も Wnn とまぜてしまって 
| 元木さん> configure のオプションで --with-japanese, --with-chinese, --
| 元木さん> with-korean, --with-taiwanese なんぞと区別するのがよいの で
| 元木さん> はないかなと思っています。
| 
| そうですね。でもどれもつけないと何も作られないというのもアレなので、デ
| フォルトで全部作成されて --without-japanese なんかで省いていくという方
| がいいかもしれません。
| 
| 実は、かなり前なのですが、Wnn4.2 (FreeWnn ではない)で、以下のようなディ
| レクトリ構成を試していました。
| 
|     libwnn --+-- Src     共通のソース
|              |
|              +-- jWnn    日本語固有のソースと、全オブジェクト
|              |
|              +-- kWnn    韓国語固有のソースと、全オブジェクト
|              |
|              +-- cWnn    中国語固有のソースと、全オブジェクト
|              |
|              +-- tWnn    台湾語固有のソースと、全オブジェクト

 多分、共通ソースが同じ CFLAGS, CPPFLAGS, DEFS 等でコンパイ
 ルできない限り、automake の利点を 100% 享受するのは難しいか
 もしれません。

 手元のautomake化中のソースでは symlink を使ったり、ちょっと
 汚い手をつかったりして全然美しくないものになっています。

| この試みは、結局 jserver とソースが分離できないという壁にぶちあたり止
| まってしまいましたが。こういう構成って automake で対応できますか? すい
| ません automake は不勉強なもので…

 私も結構不勉強なので以下 automake に対する思い込みがあるや
 もしれません。

 automake にするのは結構ダメージが大きいかも知れません。

 私が思いつくものでは、(たくさん抜けていると思いますが)

 メリット

 o Makefile, Makefile.in Makefile.am の保守が容易。
 o libtool に対応するのが容易。 (shared library 作るのも簡単)
 o 結構なにも考えなくても Makefile の品質が上がる。

 デメリット

 o ソースの形がある程度 automake に制約される。

  - automake の利点を享受するならば あるプログラムが必要とす
    るソースファイル(.c)は一つのディレクトリにまとまっている
    のがのぞましい。

  - 同じディレクトリ内で複数のプログラムに対してコンパイル時
    の CFLAGS, DEF, CPPFLAGS を変えるのが困難。
    (もちろん configure しなおすなら問題ないですが...)

 上の欠点とくっついて FreeWnn だとかなりきついことに
 なります。同一ディレクトリで各言語のオブジェクトがコ
 ンパイルできない

 ほんとに厳密に automake しちゃうと全部 build するなら
 CONFIGURE="../configure --cache-file=../config.cache"
 (mkdir jserver && cd jserver && $CONFIGURE --with-jserver && make) && \
 (mkdir cserver && cd cserver && $CONFIGURE --with-cserver && make) && \
 (mkdir kserver && cd kserver && $CONFIGURE --with-kserver && make) && \
 (mkdir tserver && cd tserver && $CONFIGURE --with-tserver && make) && \
 (mkdir libjwnn && cd libjwnn && $CONFIGURE --with-libjwnn && make) && \
 (mkdir libcwnn && cd libcwnn && $CONFIGURE --with-libcwnn && make) && \
 (mkdir libkwnn && cd libkwnn && $CONFIGURE --with-libkwnn && make) && \
 (mkdir libtwnn && cd libtwnn && $CONFIGURE --with-libtwnn && make) && \
 (mkdir jutil && cd jutil && $CONFIGURE --with-jutil && make) && \
 (mkdir cutil && cd cutil && $CONFIGURE --with-cutil && make) && \
 (mkdir kutil && cd kutil && $CONFIGURE --with-kutil && make) && \
 (mkdir tutil && cd tutil && $CONFIGURE --with-tutil && make)
 とかするはめになるかもしれません (^^;

 逃げ道としては上記を取捨選択的に実行する configure をつくって
 ./configure --enable-jserver --enable-libjwnn --enable-jutil 
  or
 ./configure --enable-japanese
 とかを考えましたが、ここまでする必要があるのかと悩んでいます。

 以上、参考になりましたら嬉しいです。

| というわけで、FreeWnn 1.2 にむけての最優先項目であると私は思っています。
| 保守しやすいソースコードにする。パワーアップはそれからですね。(だって、
| ソースコードの構成を変えてしまったらパッチが当たらなくなるし…)

 ちょっと現状の構成はきついものがあるので、このような構想は
 非常に嬉しく思います。
 ありがとうございます。

sin.
とりあえず手元でやってみるかなぁ