dcmodel に関する諸々の打ち合わせ 2005/06/02

日時・参加者

日時

6/2 (木) 13:30 -- 18:30

場所

北大理学 8 号館 8-2-08 (林部屋)

参加者

林, 石渡, 小高, 柿並, 杉山, やまだゆ, 森川, 北守, 加藤

dcmodel 群で共通化しているルールの確認

ルールに関する文書は以下に置く.

<URL:http://www.gfd-dennou.org/arch/dcmodel/doc/TEBIKI.dcmodel-souron.htm >

Fortran90 ソースコードの記述に関するルール

Fortran90 の書法

「変数命名規則」および「書法」.

それらに関する参照ドキュメントは未作成. dcmodel 領域にこれらを具体的に記した文章をおく予定.

Fortran90 プログラムのリファレンスマニュアル作成方法

Fortran90 の内部に RD 的書法のコメントを埋め込み, そこから rdtool を用いてドキュメントを生成する.

現在参照ドキュメントなし.

今後, rdoc への移行を検討中.

プログラム開発に関してのルール

cvs リポジトリのおき方

以下の URL の「各種モデルプロジェクトディレクトリの構造」を参照せよ.

<URL:http://www.gfd-dennou.org/arch/dcmodel/doc/TEBIKI.dcmodel-projectdir.htm>

cvs ログメッセージの記述の仕方に関して

現在作成中

<URL: http://www.gfd-dennou.org/arch/dcmodel/doc/TEBIKI.dcmodel-cvslog-rule.htm >

cvs タグのつけ方に関して

現段階では dcmodel としての共通ルールはなし.

共通化されていない各モデルごとのルールは, 各プロジェクトのページの TEBIKI に作成されている. (これらをマージする予定)

Web で公開する資料に関して

各プロジェクトのソースコードの公開の仕方

開発メモ

打ち合わせの際のメモ書きや, 個人の (他に適当な置き場の無い) モデルに関する メモ書きは, プロジェクト直下の memo ディレクトリに置く. 書式は固定しない. ファイル名のルールのみは固定する. 以下の URL の 「memo/作業履歴ディレクトリ」 参照のこと.

<URL: http://www.gfd-dennou.org/arch/dcmodel/doc/TEBIKI.dcmodel-projectdir.htm >

モデル実験の結果の公開方法

以下で公開される, dcmodel-thum.rb を用いる.

<URL: http://www.gfd-dennou.org/arch/dcmodel/doc/dcmodel-tools/dcmodel-thum-sample/sample_thum.htm >

Web ページの顔つき

各プロジェクトページで, 各項目の並べ方をそろえる.

日本語と英語の両方を作成する.

スタイルシートは

<URL:http://www.gfd-dennou.org/arch/dcmodel/htmltools/dcmodel.css >

を用いる.

外向けに公開する部分に関しては, RD で書くにせよ HTML で書くにせよ 上記のスタイルシートを利用すること.

RD で記述する場合の書式に関して

dcmodel 関連のメモ書きなど, RD で記述する場合の書法の手引きが必要. dcmodel/doc 以下に作成する.

ルールに関する問題点

「RD でつくる dcmodel プロジェクト」手引きが未整備

詳しくは下記の dcmodel 関連のドキュメント整備 を参照のこと.

Web 公開用資料の書式は?

ドキュメントの作成を, どこまでは RD を強制し, どこから HTML などのほかの 書式を許容すると良いのかはまだ分かっていない.

dcmodel 関連のドキュメント整備

RD に関して

deb パッケージ作成の自動化

rpm を dennou で作るのは困難であると予想されるので, rpm の自動生成は とりあえずあきらめる. (開発グループに rpm を用いるユーザが居ないというのも 原因のひとつ).

deb パッケージも現在のメンテナである小高さんにとって自動化するための ツールを作成する方が手間であるとの話から, 自動化はあきらめる. deb パッケージをメンテナンスするよりは Mkinclude や Config.mk などの 生成 or 編集のすべを鍛える方にエネルギーを傾ける.

autoconf の利用に関して

Mkinclude や Config.mk を自動生成するために良く用いられるスクリプトとして「 configure 」 があり, その configure を自動生成するツールとして autoconf がある.

しかし autoconf はその習熟に時間がかかる (敷居が高い) ため, dcmodel でみんなで利用するには少々困難である.

現状では最低限, Mkinclude や Config.mk を編集するための手引きを整える ということのみ義務とする.

cvs ソースの展開の自動化

自動化に用いる Makefile が複雑になっているため, 役割に応じて Makefile を分割すべきかもしれない.

議論に十分な時間を割けなかったので, 次回に持ち越し.

今回の議論では, 以下のようになっていると良さそうという意見に とどまった.

gtool4/Makefile
       Makefile.rd2html
       Makefile.export

       html/Makefile
       gt4f90io/Makefile
       gt4ncconf/Makefile
gtool4/Makefile

詳しいことは記述せず, 各 Makefile へのリンクに近いもののみ記述

# 具体例

all: html

html:
        make -f Makefile.rd2html

export:
        make -f Makefile.export
gtool4/Makefile.rd2html
(議論不十分) gtool4 直下の rd を html 化
gtool4/Makefile.export
(議論不十分) gtool4/gt4f90io/Makefile や gtool4/gt4ncconv/Makefile に関するヘルプメッセージの出力, もしくはそれらの Makefile を直接 読み込んでしまう.