[freewnn:00568] cpp for pubdicplus (Re: cvs server for freewnn.org)

[aono@XXXX (Tomoki AONO)]

大阪教育大の青野と申します。お騒がせしてすみません。
＃やはりちゃんと試してから投稿すべきだったと後悔しています。

<200105160937.SAA00409@sranhm.sra.co.jp>の記事において
yabuki@sranhm.sra.co.jpさんは書きました。

>> 現状(FreeWnn-1.1.1-a017)でも実は AC_PROG_CPP を使っています．
>> ただし，Xsi/configure.in の AC_PROG_CPP の現れる直前で，
>> プラットフォーム毎に CPP やその他のマクロを定義している部分があります．
>> AC_PROG_CPP は，CPP が*定義されていなければ*，いくつかテストを
>> 行ない，CPP の適切なコマンドを見つけようとします．
>> ここで行なわれるテストは，C の小さなコードを使って行なわれるので，
>> やはり，C のソースコード以外に適用することは考慮されていません．

実際にconfigure.inを変更するまで気づきませんでした。

少し考えて見たのですが、(例えば)gccならば '-x c'を$CPP (か
$CPPFLAGS / $FZK_FLAG)に追加する処理にすると、元の阿部さん
の '-print-prog-name=cpp' と同じ感じになってしまいます。な
らば、個人的には後者のままの方がよいと思います。
＃'-x'オプションが'-print-prog-name'よりも多くの(古い?)gcc 
＃でサポートされているのならそちらを使う意義がありますが…。

>> で，この，辞書ファイルの生成(という理解で良いのかどうか実は
>> 知らないのですが)に使われる cpp をどうするかに限っていうと，
>> 対処方法としては，以下のようなものが思いつきますが，いかがでしょうか?
>> 
>> (1) 現状のように，configure.in で必要なプラットフォーム毎に CPP を設定する
>>     cc -E で駄目な場合は，cpp コマンドのパスを書く．
>>     (gcc が使える場合は，gcc -x c -E を書いてもよい)
>> 
>> (2) AC_PROG_CPP に代わるマクロ AC_PROG_CPP_NOT_FOR_C みたいなものを
>>     書いて，gcc が使える場合には CPP に gcc -x c -E を設定するようにする．
>> 
>> (3) 生成される辞書ファイルは多分プラットフォームには依存しないだろうか
>>     ら(本当?)，make 時に生成するのではなく，ディストリビューションにあらかじ
>>     め生成したものを入れておく．こうすれば，これの生成担当者の人が，
>>     自分の環境の CPP の心配だけすれば良い．
>> 
>> (4) そもそも cpp は C 言語向けなので，他のファイルに使うといらぬ
>>     副作用があるやもしれないので，もっと別の方法で辞書ファイルの
>>     生成を行なうようにする．

個人的には(3)か(4)がよいと思います。しかしもしpubdic+の部
分がas-isのままで取り込まれているのならば、変に追加・変更
するのがよいのかが少し気になります。(1)ベースのパッチを
（誰も手を上げなければ、叩き台として）作ってみましょうか?
----
大阪教育大学 情報処理センター
青野智樹	(aono@cc.osaka-kyoiku.ac.jp)
＃情報処理センターに関するお問い合わせは 
＃center@cc.osaka-kyoiku.ac.jp へお願いします。