search

texjporg / platex

pLaTeX community edition
BSD 3-Clause "New" or "Revised" License
49 stars 8 forks source link

Travis CIの設定を追加 #19

Closed y-yu closed 8 years ago

y-yu commented 8 years ago

11 で議論があったことですが、ドキュメントを自動でデプロイするとかは一旦おいておいて、ひとまず変更した後で正しくコンパイルできるのかについて検証するTravis CIの設定ファイルを追加しました。

もしこの変更を取り込む場合は、次のWebサイトに従ってTravis CIとGithubのリポジトリの設定をしていただきたく思います。

なにか不明な点がありましたら、お気軽に質問してください。

aminophen commented 8 years ago

正しくコンパイルできるのか

jsclasses のほうで話題に上ったのですが、『リポジトリに置いてあるソースからドキュメントのビルドが通るかどうか』はあまり役に立たないと考えるようになりました。というのも

からです。この問題を避けるため、少なくとも jsclasses でプルリクを open するときは、「ワザと \CheckSum を変更しない」という方法を取るような暗黙の合意ができつつあります。つまりビルドが通らない状態が頻繁に発生します。

リリース時に限ればビルド可能である必要がありますが、それ以外の場合にエラーが出るのが嫌かもしれない、と私は思っています。

aminophen commented 8 years ago

一方で、\CheckSum というのは単に0と書いておくと、「警告だけ（\CheckSum の値はこれこれが正しいよという警告）が出てビルドは通る」という挙動になります。この挙動を利用するなら、conflict が起きず、かつビルドも（警告は出るが）通ることにできます。

y-yu commented 8 years ago

なるほど。\CheckSumという仕組みを今始めて知り、ちょっと驚いています。

\CheckSum というのは単に0と書いておくと、「警告だけ（\CheckSum の値はこれこれが正しいよという警告）が出てビルドは通る」という挙動になります。

そうですね。もしTravis CIなどなんらかのCIを使うなら、Travis CIによるコンパイル時だけは\CheckSumを0にするような方法が有効かもしれないですね。

aminophen commented 8 years ago

LaTeX の docstrip における \CheckSum という仕組みは、ネットワーク回線が貧弱だった黎明期に「dtx ファイルのダウンロードに失敗して途中までしか取得できなかった場合に気づくように」という目的で作られました。いまの時代にこれは大して役に立たないことから、現在の LaTeX チームはかの有名な「2015年の大改訂」の中で「\CheckSum をそもそも書かない」という運用も可能なように変更しています。（2014年までは「\CheckSum 無しはダメ、0だと警告、異なる値だとエラー」と相当厳しかった。）

いまの時代ならば、texjporg の全リポジトリで \CheckSum をゼロにする、というのはアリかもしれないのですが、どうでしょう。

aminophen commented 8 years ago

これは「正しくコンパイルできるか」とは外れますが、Travis CI のログを見てみると

$ make all

platex -kanji=jis plfmt.ins
This is e-pTeX, Version 3.14159265-p3.7-160201-2.6 (jis.euc) (TeX Live 2016) (preloaded format=platex)
 restricted \write18 enabled.

kpathsea: Running mktexfmt platex.fmt
mktexfmt: mktexfmt is using the following fmtutil.cnf files (in precedence order):
mktexfmt:   /usr/local/texlive/2016basic/texmf-dist/web2c/fmtutil.cnf
mktexfmt: mktexfmt is using the following fmtutil.cnf file for writing changes:
mktexfmt:   /Users/travis/Library/texlive/2016basic/texmf-config/web2c/fmtutil.cnf
mktexfmt [INFO]: writing formats under /Users/travis/Library/texlive/2016basic/texmf-var/web2c
mktexfmt [INFO]: --- remaking platex with eptex
mktexfmt: running `eptex -ini   -jobname=platex -progname=platex *platex.ini' ...
This is e-pTeX, Version 3.14159265-p3.7-160201-2.6 (utf8.euc) (TeX Live 2016) (INITEX)
 restricted \write18 enabled.
entering extended mode
(/Users/travis/build/y-yu/platex/platex.ini
<<< making "platex with Babel" format >>>

(/usr/local/texlive/2016basic/texmf-dist/tex/platex/base/platex.ltx

とあって、Travis CI は「platex.fmt がなければ自動で作る」という嬉しい挙動になっています。しかし、その platex.fmt 作成時に、可能ならば「いまリポジトリにある platex.ltx, plcore.ltx etc.」を読んでほしいのですが、なぜか BasicTeX にもともと入っている platex.ltx などを読み込むようです。ここを改善できれば、自動デプロイも視野に入れられるのですが、なんとかならないかなあ…

kmaed commented 8 years ago

いまの時代ならば、texjporg の全リポジトリで \CheckSum をゼロにする、というのはアリかもしれないのですが、どうでしょう。

\CheckSum については詳しくないのですが，書かれている通りならば「そもそも書かない」でもよいような気がします．

なぜか BasicTeX にもともと入っている platex.ltx などを読み込むようです。ここを改善できれば、自動デプロイも視野に入れられるのですが、なんとかならないかなあ…

ログを見る限り，直前で make clean (make all も？) で platex.ltx を削除しているためのように見えます．

aminophen commented 8 years ago

書かれている通りならば「そもそも書かない」でもよいような気がします．

2015年以降の LaTeX を前提とすればそもそも書かないも ok ですね。そこで LaTeX2e svn をみてみると、docstrip の説明文書の dtx 以外にはそもそも \CheckSum を書いていませんでした。ということなので、そうしましょうか。

直前で make clean (make all も？) で platex.ltx を削除しているため

そうでした… Travis CI の設定で「clean する前に fmtutil を走らせて一旦作っておく」とすればどうにかなりそうですね。ありがとうございます。

aminophen commented 8 years ago

Travis CI をもう少し理解しようと思いまして、aminophen/travis ブランチで generated なファイルを削除した状態にし、そこから Travis CI の設定ファイルを作ってみました。

これで build pass するところまでは確認しました。

aminophen commented 8 years ago

LaTeX 本家の変更

2016-02-12  Frank Mittelbach  <latex-bugs@latex-project.org>

    * doc.dtx: Suppress \CheckSum check if no checksum is given in the file.

2016-02-12  David Carlisle  <latex-bugs@latex-project.org>

    * Lose \CharacterTable and \CheckSum from various documentation files.

に追随し、すべての dtx から \CharacterTable と \CheckSum を削除しました (52fc5d8) 。古い LaTeX（2006年頃）でも問題なくコンパイルできるようですので、実害はないはずです。

y-yu commented 8 years ago

みなさん、ありがとうございます。議論を参考にいろいろと改良してみました。

makeについて

Travis CI をもう少し理解しようと思いまして、aminophen/travis ブランチで generated なファイルを削除した状態にし、そこから Travis CI の設定ファイルを作ってみました。

これを参考にしまして、次のようにmakeの実行を変えさせていただきました。

script:
  - make
  - rm -f *.dvi
  - fmtutil --byfmt platex
  - make all

テストを実行するOSについて

最初の.travis.ymlではOSXでのみコンパイルを行っていまして、やや公平性に欠けるところがあったので、LinuxにもTeXLive2016をインストールして同時にテストするように変更しました。これには下記のスクリプトを用いています。

https://github.com/y-yu/install-tex-travis/blob/master/install-tex.sh 　 僕がforkしたリポジトリで試した結果は次のようになっています。

https://travis-ci.org/y-yu/platex/builds/155721602

aminophen commented 8 years ago

すみません、まだ理解不足で Travis CI を導入するメリットがよくわかっていません。主に

の2点です。ちなみに私自身の開発環境は主に Win32 で、TeX Live ではなく W32TeX ですので微妙に異なり、仮想環境でのテストとは異なる結果になる可能性があります。

もう一点、こちらは管理の問題ですが、私は管理権限を持ってませんので、この texjporg/platex リポジトリの Settings タブを開けませんので Travis CI のアクティベートができません。

y-yu commented 8 years ago

順番に僕の考えていることを説明したいと思います。

  • 自動デプロイしない場合にチェックだけ走らせるメリット

これについてですが、たとえば今後、プルリクエストなどで貢献してくれるような方が増えた際に、そのプルリクエストの度にメインの開発者が修正をダウンロードしてコンパイルしてみて動くことを確認するのは少々骨が折れると思います。そこで、ひとまず送られてきたプルリクエストなどが少なくともコンパイルに通っているものであることは保証しておいた方が、楽なのではないかと考えています。

  • テスト実行する OS を増やすメリット

これについては、僕の推測になりますが、開発者は自分の開発環境でだけでmakeなどを実行して成功するかどうかを確認しているので、抜けがあったりするのではないかと思います。たとえばMakefileの中でOSによって微妙に挙動が異なるsedのようなプログラムを使用し始めた場合、思わぬバグを埋め込んでしまう恐れがあると思います。よって、修正がなるべく多くのOSで動くことを保証した方がよいと考えたので追加させていただきました。

ただ、どちらにしてもあくまで僕の考えですので、議論があってもよいと思っています。

aminophen commented 8 years ago

1点目

「プルリクをマージするときにコンパイルを走らせない」というのは危険すぎて、まずアリエナイ、と思います。すでに forum:1967 にまとめた通り、3回バグを出しています。これは「リポジトリは当然コンパイル通るけど、ユーザ側が特定の使い方をするとダメ」というものばかりでした。pLaTeX にバグが入ることは相当な影響がありますから、各コミットやプルリクのマージ（TeX コードの変更）を相当慎重に行いたいと考えています。なので、リポジトリだけテストできても不足だと思います。

2点目

ソースファイルは全て TeX 言語で書かれていますし、TeX 言語に“方言”のようなものはありません。従って、sed を使うことはないでしょう。（“微妙な差異が気になるツール”の中で、仮に使うとすれば iconv くらいでしょうか。）ちなみに Makefile は、私自身が Win32 (MSYS1) / MacOS / Debian の全てで使えることを確認しつつ書いたもので、「Makefile が原因でビルドが通らない」ということはほぼあり得ないと思います。OS 間の差異をテストするのであれば、Win32 の仮想環境も追加したほうが、信頼性が高まります。

aminophen commented 8 years ago

リポジトリは当然コンパイル通るけど、ユーザ側が特定の使い方をするとダメ リポジトリだけテストできても不足だと思います。

ある程度 dtx ファイルや docstrip の仕組みに詳しくならないと難しい気がしましたので、補足します。

pLaTeX 本体コードの実装はすべて TeX 言語で書かれています。ところが、いま Makefile でやっていることは、「pLaTeX 本体コードが“がっちりガード”されたソースファイル」から

  1. TeX を使って“ガード”を剥ぎ取り「pLaTeX 本体コード」をストリップする（→ このとき pLaTeX 本体コードの内容そのものは解釈されない）
  2. TeX でコンパイルして「pLaTeX 本体コードを verbatim 環境に入れたようなドキュメント」をビルドする（verbatim なのでここでも内容そのものは解釈されない）

だけ、なんですよね。なので、「make が通る条件」はきわめてガバガバです（注1）。

一方、バグを出しているのは、ユーザが platex を実行した際に発生する「pLaTeX 本体コードが解釈される過程」での出来事です（注2）。

注1：1. の“ガード”の仕方が文法的に間違っているとか、2. の verbatim 環境の外側の文章が文法的に間違っているとか、があれば make が通らないのですが、稀でしょう。）

注2：fmtutil を走らせる過程を私が .travis.yml に追加することに拘りましたが、あれはその後に続くドキュメントのビルドの準備です。fmtutil を実行しておくことで、それに続くドキュメントのビルドでは“そのドキュメントに必要な部分だけ”「本体コードの解釈結果」が読み出されます（若干不正確な表現ですが）。とはいえ、この段階で拾えてしまうようなバグはごく稀でしょう。

aminophen commented 8 years ago

（連投すみません。）

いろいろ今回勉強になりました。個人的に考えたことを書きます：

せっかく Travis CI のような CI を使うのであれば、がばがばであんまり意味のないテスト（私の上の主張が真だとするならば、ですが）だけに使うよりは、自動デプロイまで行ってしまうとか、意味のあるテストに使うとかのほうがよいと思います。「意味のあるテスト」というのは『今淋しい状態の tests/ ディレクトリをもっと充実させて、そこのビルドが通るかどうか』みたいなことです。問題は「バグを誘発しそうなテストケースをどうやって作るか」だったりします。このテストケース作成がいままで不十分で、バグを3回も出しているわけですが。

y-yu commented 8 years ago

僕の意図としては、#11 の議論がひとくぎりあって止っていたので、なにかできる部分から手をつけたかったのですが、それでは意味がないという主張ももっともだと思うので、いったんクローズさせていただくことにします。

aminophen commented 8 years ago

リポジトリの構成を最初から CI と親和性の高いやりかたにしておけば、楽にマージできたかもしれませんが、アスキーから”モノ”だけ引き取って手探りで始めた勉強不足な身としてはとても考えが及びませんでした。私の fork では暇を見て、勉強がてら「意味のあるテスト」に使えるまで温めることにします。

（意味のあるテストといえば、#17 のバグ誘発ソースありがとうございました。こういうのはなかなか開発側で思いつきませんので貴重です。今後ももし見つけたときはぜひ送ってください。）