1
0
Fork 0
mirror of https://github.com/ruby/ruby.git synced 2022-11-09 12:17:21 -05:00

inilne markups

* README.ja: separate inilne markups from multibyte sequence by
  spaces, so that another implementation can parse them properly.

git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@35529 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This commit is contained in:
nobu 2012-05-03 15:09:41 +00:00
parent aa913eb6fa
commit 4b0e5edaea

View file

@ -88,32 +88,32 @@ Ruby拡張モジュールについて話し合うruby-extメーリングリス
以下の手順で行ってください.
1. もし+configure+ファイルが見つからない、もしくは
+configure.in+より古いようなら、+autoconf+を実行して
新しく+configure+を生成する
1. もし +configure+ ファイルが見つからない、もしくは
+configure.in+ より古いようなら、 +autoconf+ を実行して
新しく +configure+ を生成する
2. +configure+を実行して+Makefile+などを生成する
2. +configure+ を実行して +Makefile+ などを生成する
環境によってはデフォルトのCコンパイラ用オプションが付き
ます.+configure+オプションで <tt>optflags=..</tt> <tt>warnflags=..</tt> 等
ます. +configure+ オプションで <tt>optflags=..</tt> <tt>warnflags=..</tt> 等
で上書きできます.
3. (必要ならば)+defines.h+を編集する
3. (必要ならば)+defines.h+ を編集する
多分,必要無いと思います.
4. (必要ならば)+ext/Setup+に静的にリンクする拡張モジュールを
4. (必要ならば)+ext/Setup+ に静的にリンクする拡張モジュールを
指定する
+ext/Setup+に記述したモジュールは静的にリンクされます.
+ext/Setup+ に記述したモジュールは静的にリンクされます.
ダイナミックローディングをサポートしていないアーキテク
チャでは+Setup+の1行目の「<tt>option nodynamic</tt>」という行のコ
チャでは +Setup+ の1行目の「<tt>option nodynamic</tt>」という行のコ
メントを外す必要があります.また,このアーキテクチャで
拡張モジュールを利用するためには,あらかじめ静的にリン
クしておく必要があります.
5. +make+を実行してコンパイルする
5. +make+ を実行してコンパイルする
6. <tt>make check</tt>でテストを行う.
@ -145,10 +145,10 @@ Ruby拡張モジュールについて話し合うruby-extメーリングリス
RubyのAPIバージョンが'_x.y.z_'であれば,<tt>${MAJOR}</tt>は
'_x_'で,<tt>${MINOR}</tt>は'_y_'<tt>${TEENY}</tt>は'_z_'です.
<b>注意</b>: APIバージョンの+teeny+はRubyプログラムのバージョ
<b>注意</b>: APIバージョンの +teeny+ Rubyプログラムのバージョ
ンとは異なることがあります.
+root+で作業する必要があるかもしれません.
+root+ で作業する必要があるかもしれません.
もし,コンパイル時にエラーが発生した場合にはエラーのログとマ
シンOSの種類を含むできるだけ詳しいレポートを作者に送ってく
@ -157,16 +157,16 @@ Ruby拡張モジュールについて話し合うruby-extメーリングリス
== 移植
UNIXであれば+configure+がほとんどの差異を吸収してくれるはずで
UNIXであれば +configure+ がほとんどの差異を吸収してくれるはずで
すが,思わぬ見落としがあった場合(あるに違いない),作者にその
ことをレポートすれば,解決できるかも知れません.
アーキテクチャにもっとも依存するのはGC部ですRubyのGCは対象
のアーキテクチャが<tt>setjmp()</tt>または<tt>getcontext()</tt>によって全てのレ
ジスタを+jmp_buf+や+ucontext_t+に格納することと,+jmp_buf+
+ucontext_t+とスタックが32bitアラインメントされていることを仮定
しています.特に前者が成立しない場合の対応は非常に困難でしょ
う.後者の解決は比較的簡単で,+gc.c+でスタックをマークしている
ジスタを +jmp_buf+ や +ucontext_t+ に格納することと, +jmp_buf+
+ucontext_t+ とスタックが32bitアラインメントされていることを仮定
しています.特に前者が成立しない場合の対応は非常に困難でしょう.
後者の解決は比較的簡単で, +gc.c+ でスタックをマークしている
部分にアラインメントのバイト数だけずらしてマークするコードを
追加するだけで済みます.<tt>defined(\_\_mc68000\_\_)</tt>で括られてい
る部分を参考にしてください.
@ -178,7 +178,7 @@ UNIXであれば+configure+がほとんどの差異を吸収してくれるは
== 配布条件
+COPYING.ja+ファイルを参照してください。
+COPYING.ja+ ファイルを参照してください。
== 著者