前回、PHPのソースコードを入手しました。今回は早速ビルドしてみます。基本はApacheと変わりませんが、いくつか注意してほしいポイントがあります(編集部)
前回はPHPの概要を説明し、ソースコードを入手してみました。今回はPHPをビルドしてみましょう。
PHPのビルド方法も、実はこれまで解説したソフトウェアと大きく異なるところはありません。configureスクリプトが同梱していますので、configureを実行して設定し、makeでビルドという流れです。これまでの連載を読んでいただければ、ビルドの手順はそれほど難しいものではないはずです。
とはいえ、いくつか要注意ポイントがあります。特にひっかかりそうなのがPHPのエクステンションです。Apache HTTP Server(以下Apache)では機能が細分化されていて、それぞれがモジュールとなっていました。PHPも同様にエクステンションという単位で機能を付け外しができるようになっています。Apacheのモジュール同様、エクステンションはconfigure実行時にビルドするかどうかを選べます。
PHPのエクステンションは数多くあります。まず、どのエクステンションをビルドすべきか、という点で迷うでしょう。迷ったからといって、エクステンションを全部ビルドするというのもちょっと無理があります。Apacheの場合、モジュールのビルドに、特定のソフトウェアが必要になるということはそれほどありませんでした。これまでの連載でもほとんどのモジュールをconfigureに指定してビルドしていました。しかし、PHPでは多くのエクステンションで、ライブラリなどほかのソフトウェアが必要になります。
動かすPHPアプリケーションが明確なら、動作に必要なエクステンションが決まっているはずですから、それに従ってエクステンションを選択すれば済みます。そうでない場合は、よく使うと思うエクステンションを有効にしておき、ビルド中にほかのエクステンションが必要になったら、その都度ビルドするということになります。
それぞれのエクステンションのビルドに必要なソフトウェアを確かめるには、PHPのサイトにあるマニュアルを見るのが早いでしょう。日本語化も行き届いています(図1)。それぞれのエクステンションごとにビルド、インストール手順をきちんと説明してあります。
もう1つのポイントはApacheへの組み込みです。前回、PHPはApacheに組み込んで利用できるということに触れましたが、具体的にはPHPをApacheモジュールとしてビルドするということになります。これは第20回で紹介した、サードパーティのApacheモジュールのビルド方法が参考になります。
PHPを組み込むApacheですが、第22回でも示した次のconfigureコマンドラインでビルドするものとします。PHPを組み込む場合、「--with-mpm」で「prefork」を指定するようにします。
./configure \ --prefix=/opt/apache-httpd-2.2.21 \ --enable-mods-shared=all \ --enable-ssl \ --with-pcre \ --with-mpm=prefork \ --with-berkeley-db \ 2>&1 | tee configure_log.txt
また、次のように開発用のパッケージがインストールされていることを前提とします。これらのライブラリはビルドせずにCentOSのものを使うことになります。
sudo yum install db4-devel openssl-devel pcre-devel zlib-devel
エクステンションは前述の通り、選ぶものによって、手順が面倒になるという問題があります。まずは、エクステンションはすべて無効にしてしまって、ApacheにPHPを組み込むことだけ考えてビルドしてみましょう。
configureスクリプトのコマンドラインは次のようになります。
./configure \ --prefix=/opt/php-5.3.8 \ --with-apxs2=/opt/apache-httpd-2.2.21/bin/apxs \ --disable-all \ 2>&1 | tee configure_log.txt
「--prefix」は、PHPのコマンドライン版やライブラリをインストールするディレクトリを指定します。ApacheモジュールのPHPは直接Apacheのインストールディレクトリにインストールされます。
「--with-apxs2」はApacheの情報を返すスクリプトを指定します。第20回で解説したように、Apacheモジュールのビルドに必要な引数です。第20回では「--with-apxs」でしたが、PHPの場合「--with-apxs」を指定するとApache 1.x系列が対象となりますので注意してください。
「--disable-all」はすべてのエクステンションを無効にする指定です。外部のソフトウェアに依存するようなエクステンションをビルドしないので、依存関係に関するトラブルはひとまず避けることができます。
configureを実行したら、これまで通り「make」と実行します。すると、最後に次のようなメッセージが表示されます。
Build complete. Don't forget to run 'make test'.
Apacheのビルドやインストールではテストという手順はありませんでしたが、PHPではテストが実行できるようになっています。これは各機能が正しく動作しているかをテストするものです。正しくビルドできているかの確認にもなりますので、インストール前に「make test」を実行しましょう。
PHPのテストは1万項目以上ありますので、しばらく時間がかかります。さて、テストの結果はどうでしょうか。次のような結果になりました。
===================================================================== TEST RESULT SUMMARY --------------------------------------------------------------------- Exts skipped : 71 Exts tested : 7 --------------------------------------------------------------------- Number of tests : 11477 6190 Tests skipped : 5287 ( 46.1%) -------- Tests warned : 0 ( 0.0%) ( 0.0%) Tests failed : 9 ( 0.1%) ( 0.1%) Expected fail : 32 ( 0.3%) ( 0.5%) Tests passed : 6149 ( 53.6%) ( 99.3%) --------------------------------------------------------------------- Time taken : 231 seconds =====================================================================
半分近くのテストがスキップとなっていますが、これはエクステンションを無効にしているため、テスト対象のエクステンションが無いと認識していることを示します。そして「Tests failed」が9件あります。これは9件のテストが失敗しているということです。「Expected fail」も失敗ではありますが、これは現時点のPHPでは失敗していてもビルドには問題ないものです。すでに判明しているバグなどがこの失敗に該当します。
テスト結果に続いて、失敗したテストの一覧が表示されます。
===================================================================== FAILED TEST SUMMARY --------------------------------------------------------------------- Bug #55156 (ReflectionClass::getDocComment() returns comment even though the class has none) [Zend/tests/bug55156.phpt] DateTime::diff() days -- spring type2 type2 [ext/date/tests/DateTime_days-spring-type2-type2.phpt] DateTime::diff() days -- spring type2 type3 [ext/date/tests/DateTime_days-spring-type2-type3.phpt] DateTime::diff() days -- spring type3 type2 [ext/date/tests/DateTime_days-spring-type3-type2.phpt] DateTime::diff() days -- spring type3 type3 [ext/date/tests/DateTime_days-spring-type3-type3.phpt] DateTime::sub() -- dates [ext/date/tests/DateTime_sub-dates.phpt] DateTime::sub() -- february [ext/date/tests/DateTime_sub-february.phpt] preg_replace() with array of failing regular expressions [ext/pcre/tests/006.phpt] Bug #54971 (Wrong result when using iterator_to_array with use_keys on true) [ext/spl/tests/bug54971.phpt] =====================================================================
この次に「Expected fail」の一覧も表示されますが省略します。そして最後に、テスト結果を開発チームに送信するかどうか訪ねられます。
You may have found a problem in PHP. This report can be automatically sent to the PHP QA team at http://qa.php.net/reports and http://news.php.net/php.qa.reports This gives us a better understanding of PHP's behavior. If you don't want to send the report immediately you can choose option "s" to save it. You can then email it to qa-reports@lists.php.net later. Do you want to send this report now? [Yns]:
ここでYを入力すると、自動的にレポートがメールで送信されます。ビルドを実行しているサーバの情報なども漏れることになりますので、実行には注意してください。sを入力すると結果を保存します。
いきなりテスト失敗となってしまいました。このようなテストの失敗は、ビルドのトラブルや、環境がおかしいことを示している可能性があります。失敗している原因を調べるべきですが、難しいかもしれません。簡単なのは、どのテストで失敗しているのかを検索することです。それが分かれば、テストが失敗していても問題はないと分かることもあります。
実際は、PHPのテストが100%成功することは筆者の経験ではあまりありません。少々のテスト失敗であれば、ビルドに大きな問題はないと見てもよいでしょう。とはいえ、具体的にどういう問題が起きて、このような結果になったのかは気になります。
失敗の原因まで突き止めることは難しいにしても、何が起きているかは知っておきたいところです。もしPHPアプリケーションで何か問題が起きたとき、テスト時に発生していた問題と同じかどうか判断する必要もあるでしょう。
次回は、失敗しているテストの結果を確認する方法を紹介します。
Copyright © ITmedia, Inc. All Rights Reserved.