make makes many prob ..
2:デフォルトの名無しさん
02/08/18 00:52
HSP使えば？
3:デフォルトの名無しさん
02/08/18 00:53
問答無用のウンコスレ
4:デフォルトの名無しさん
02/08/18 00:59
Antがアリます。
5:デフォルトの名無しさん
02/08/18 01:00
Antだけに
6:デフォルトの名無しさん
02/08/18 01:07
Antツバキは恋の花
7:デフォルトの名無しさん
02/08/18 01:12
あんと〜あん〜と〜
ｸｿｽﾚだけどスレタイ気に入った。
8:デフォルトの名無しさん
02/08/18 01:17
make love
9:1
02/08/18 01:18
>>7
ありがとうございます。
日本人相手なら早口言葉としても使えます(多分)
MMMP と覚えてください。
10:デフォルトの名無しさん
02/08/18 01:33
HSP使えばいいのに
11:デフォルトの名無しさん
02/08/18 01:33
make(・∀・)ｷﾀｰ。
結構期待してたわん。
12:デフォルトの名無しさん
02/08/18 01:49
gmakeで統一しろよ
そうすりゃ方言なんて気にしなくていいだろ。
13:デフォルトの名無しさん
02/08/18 02:52
ここはmake叩きスレというわけではないよな？
VC++のメニューに
メイクファイルのエクスポート
ってのがあることを思い出した。
あれはイイもの？普通？クソ？
（自分が使う機会があるかどうか微妙だけどとりあえず聞いてみる）
14:1
02/08/18 03:09
>>11, >>13
どちらかというと make を語るスレです。
なんか一個も make のスレが無かったので立てました。
15:デフォルトの名無しさん
02/08/18 03:16
automake使えば、makeがgmakeか、gじゃないmakeか判定して、
よきにはからってくれたようなきがする。
automakeで生成したMakefileがHI-UXのmakeでも通ったし。
16:デフォルトの名無しさん
02/08/18 03:32
automake・・・・
なんでmakeごときがあんなに複雑(そう)になるのかね？
17:question
02/08/18 22:57
本に載っているアルゴリズムのプログラムを打ち込んでコンパイルして勉強中です。
するとディレクトリの中に短く単発のソースとバイナリがいっぱいできます。
Makeを使って、Makefile内にソース名を打ち込まないで、
ソースと同名のバイナリをコンパイルすることはできませんか？
具体的には、ディレクトリの中が
seive.cpp shellsort.cpp tree.cpp quicksort.cpp
みたいになってるんです。それを >make 一発で
seive.cpp seive.exe shellsort.cpp shellsort.exe
tree.cpp tree.exe quicksort.cpp quicksort.exe
になるようにできませんか？
この後もどんどん細かいソースが増えるので、Makefileを書き直すのが面倒です。
でも特徴として、１ソース１バイナリになっているので可能な気がします。
18:shige
02/08/18 23:12
Makefileを書き換えずにやるのは無理じゃないか？
新しいファイルがディレクトリにあった場合Makefileを更新するツールを
スクリプト言語で書いた方が手っ取り早いだろう。
19:デフォルトの名無しさん
02/08/18 23:27
SOURCE:=$(wildcard *.cpp)
20:デフォルトの名無しさん
02/08/18 23:30
Antよりmakeの方が簡単
21:shige
02/08/18 23:33
なるほど。
22:デフォルトの名無しさん
02/08/18 23:57
ascii の FTP に、GNU Make のマニュアル日本語版があるよ。
>>1 のページに書いてあるようなことは卒業した人にお勧め。
23:デフォルトの名無しさん
02/08/19 00:36
>>16
システムの全ての必要な要素について、
それがあるか？、またそのバージョンは？
って調べていくんだから、そりゃ大変な作業だろ。
Windowsみたいにまとまってねーんだよ。UNIXは。
微妙な差異がものすごくめんどくさい。
24:デフォルトの名無しさん
02/08/19 03:45
>>23
Windowsだってまとまってねーんだよ。
NTと95は全くの別物。
25:デフォルトの名無しさん
02/08/19 19:48
>>23
いや、それは Autoconf と突っ込んでみる。
Makefile より Makefile.am の方が簡単だと思うし、
自分のところで動けばいいなら autoscan した後、
$ mv configure.scan configure.ac
して、
- AC_CONFIG_HEADER([config.h])
+ AM_INIT_AUTOMAKE([foreign])
- AC_CONFIG_FILES([])
+ AC_CONFIG_FILES([Makefile])
するだけで結構うまくいったりするが、どうよ。
高度な事すると結構面倒だけどね。
26:デフォルトの名無しさん
02/08/19 23:27
Minix のころは make から cc よぶメモリが足りなかったら make -n > hoge; sh hoge とかできたもんだ... あの頃は simpleだったのう。
27:デフォルトの名無しさん
02/08/19 23:31
Antじゃダメなん?
うちの会社、ソースはC++だけどAntでビルドしてるけど、それって異端？
28:デフォルトの名無しさん
02/08/19 23:43
>>27
Javaならね。
UNIXはMakeの資産があるからAntが使われることはないと思う。
29:27
02/08/19 23:44
(´-`).｡ｏＯ(うちの会社は異端かぁ)
30:デフォルトの名無しさん
02/08/20 00:13
>>27
実行形式がJavaってだけで、動かないプラットフォームがでてくるし。
研究室の古株のDigitalUNIX(not Tru64)、IRIXの古いの、HI-UX、HP-UXあたり。
ライセンスとかハードウェアの関係で最新OSにすることはできないことが多い。
31:
02/08/20 01:23
逆にJavaの開発でmake使ってる人っているんか？
32:デフォルトの名無しさん
02/08/20 03:35
何だってこんな糞ツールがここまで普及したんだろう？
UNIXの連中ってアフォばっかりだな
33:デフォルトの名無しさん
02/08/20 06:08
UNIXはもっとLispに学ぶべきだ
34:デフォルトの名無しさん
02/08/20 17:28
>>29
(´-`).｡ｏＯ(そんな会社にいたんかぁ)
35:デフォルトの名無しさん
02/08/20 22:18
>>32
融通効くからじゃない？行頭のTabを忘れなければ…。
ビルドの為に手間をかけるのが面倒だったからかもしれんし。
>>33
Lispでmakeに相当するもの…ですか？
36:
02/08/21 00:20
>>27
C++だとmakedependしたいからやっぱりmake
37:デフォルトの名無しさん
02/08/21 01:30
>>36
make depend って、私はいつも gcc -MM でやってるんですが、
他に何か定石的なやり方ってあります?
38:デフォルトの名無しさん
02/08/21 01:34
本来makeの機能ってコンパイラ自身が持っておくべきだと思うんだけどな。
んでpre/postな処理はsh/perlあたりでやればすっきりするはずだよ。
makeって機能が貧弱なわりに（そのせいでか？）人によって
書き方がかなり変わってきてメンテしづらいんだよな。
39:デフォルトの名無しさん
02/08/21 02:06
変態的なマクロとか
環境変数との関係とか
make依存の痴漢ルールとか
そのへんがイヤン
40:デフォルトの名無しさん
02/08/21 02:42
>>37
Xのmakedepend
41:デフォルトの名無しさん
02/08/21 02:47
元となる C言語が貧弱すぎたからな。あと、リンカも貧弱すぎたのかも。
だから makeで外部的に一生懸命書く必要があった。
まあ、逆に Cが貧弱だから、あの程度の仕組みで分割コンパイルの
恩恵にあずかれたのかも。
C++なんか、分割コンパイルをまともに働かせるようにするの
大変そうだし。
42:デフォルトの名無しさん
02/08/21 02:52
別にmakeはCのためだけにあるわけではない。
43:デフォルトの名無しさん
02/08/21 02:58
>>41
とはいえUNIX的ミニマリズムはいい加減古びつつあるような。
PerlやApacheなんかは単体のツールとしてどんどん複雑になっていくように
他のツールも高機能化・複雑化していくのは自然な流れでしょう。
>>42
それがよくない
make setupなんてやるなら
bash setupにしてくれよ。
44:デフォルトの名無しさん
02/08/21 11:14
>>40
サンクスです。makedepend ってツールの名前だったのね。
ちょっと使ってみたけど、たしかに速い。
あと、gcc -MM みたいに、< > で囲んだやつは無視して
くれるともっとよかったけど。
45:デフォルトの名無しさん
02/08/24 18:28
>>43
自分でツールを作りながら処理するような場合は、やっぱり
makeの枠組で出来た方が有難い。
46:デフォルトの名無しさん
02/08/24 18:37
んだんだ。makeとコンパイラはやっぱり分かれてた方がいい。
勝手にされたらされたで不満がでるはず。
47:デフォルトの名無しさん
02/08/25 12:30
>>43
make setupなんて見たことないぞ。
48:デフォルトの名無しさん
02/08/29 04:16
age
49:デフォルトの名無しさん
02/08/29 04:34
VC系の超貧弱makeのことを書いているヤシがいるような
あれはmakeと呼ぶのもおこがましいが...
50:デフォルトの名無しさん
02/08/29 04:35
vc系って何？
makeと呼べる基準って何？
51:デフォルトの名無しさん
02/08/29 12:49
>>2 は何が言いたかったのだろうか。
52:gmake
02/08/30 03:55
|-- mona
| |-- Makefile
| |-- sample.xml
| |-- mona.c
| `-- mona.h
|-- 2ch.so
↑のようなディレクトリ構成の時、
既にある2ch.soを用いてmonaディレクトリでmakeして、
monaってsoつくりたいんですけど、どーやればいいんでしょうか？
誰か助けてください。
53:gmake
02/08/30 04:14
あ、monaっていう実行ファイルでした^^;
54:デフォルトの名無しさん
02/08/30 05:28
>>52
$CFLAGSで出力先を変えればいいだけじゃないの？
-o オプションかね。
55:52
02/08/30 08:25
>54
んーっと、
|-- mona
| |-- Makefile
| |-- sample.xml
| |-- mona.c
| |-- 2ch.so
| `-- mona.h
2ch.soの生成をこうスレって話ですか(？
上の階層のアドインみたいな形にしたいんですけど、毎度コンパイル
しないと駄目なんすかね？
（既にあるのでそれを活用したい）2ch.so生成するルールがねーぞ、
ｺﾞﾙｧってでまふ。
56:デフォルトの名無しさん
02/08/30 18:20
>>55
あなたの日本語が理解できないのだが、
-o やら -L やらで簡単に解決する話のような気がする。
57:デフォルトの名無しさん
02/08/30 19:17
>>55
> （既にあるのでそれを活用したい）2ch.so生成するルールがねーぞ、
> ｺﾞﾙｧってでまふ。
ライブラリパスの設定するだけかも。
2ch.soを作成するのは？ってことならlibtoolでも使ってくれ。
58:52
02/08/31 04:41
パス設定して、でけたー
さんくすこ>56-57
59:デフォルトの名無しさん
02/08/31 11:08
make makes a massive mess.
ってのを思いついた。そんだけ sage
60:デフォルトの名無しさん
02/08/31 12:59
make makes me mad. はどう?つーか、いま FreeBSDの kernel buildでエラーでたから makeをおってるんだけど、さっぱりわかんねー。kmod.mk が動くときの cwdはどこなんだ?
61:デフォルトの名無しさん
02/08/31 15:07
make makes macro maze.
62:デフォルトの名無しさん
02/08/31 23:00
make makes me mad.
63:デフォルトの名無しさん
02/09/01 10:33
make makes more money.
だったらいいなぁ
64:名無し人間
02/09/02 00:12
>>38
web pageの更新にもmakeを使ってるから、
C compilerに統合されたら困るよぉ。
ところで、>>17には>>19で通じたんだろうか?
65:デフォルトの名無しさん
02/09/02 00:24
MS製品のVC++、FrontPage(HTMLエディタ)ともに
make的な機能が統合されてるよ。
思うにUNIXにOOPLが普及してmakeクラスがあればもっと使いやすくなるのでは。
66:デフォルトの名無しさん
02/09/04 10:53
>>65
makeクラスってどういう意味？
67:デフォルトの名無しさん
02/09/04 11:34
MSのmakeはNanchatte make
68:デフォルトの名無しさん
02/09/04 18:56
俺思うんだけど, コマンドラインで実用に耐えるコマンドがUnix系OSに比べて遥かに少ない
Windowsで, makeなんて使いモノになるの?
Windowsで仕事したことないから分からんのだけど, だれかおせーれ.
69:デフォルトの名無しさん
02/09/04 23:21
>>68
> Windowsで, makeなんて使いモノになるの?
libtiffをVC++6で利用するためにnmakeを利用したけど、
自分でhoge.makを書く気にはならんかった。
70:デフォルトの名無しさん
02/09/05 00:06
>>68
cygwin使え。
71:68
02/09/05 01:26
>>69
やっぱりそうだよね.
>>70
cygwin使うくらいならWindowsなんて使わんよ(笑). 仕事でWin触ることはあり得ないからイイっす.
72:デフォルトの名無しさん
02/09/07 02:14
そもそもWindowsがCUIのためのOSじゃないってことなんだろうな。
だからcygwinは ｲｲ（・∀・）!! わけで。
CUIが好きなのにWindowsを使う人はmake犬。
73:デフォルトの名無しさん
02/09/07 02:21
>>66
UNIXの欠点はすべてのコマンドがプロセス毎に独立してしまっていて
通信手段は貧弱なパイプしかない。
そこでmake, sort, grep等のコマンドをすべてクラス化してしまって
同一プロセス内で使えるようにすればもっと使いやすくなるのではと推測してみる。
74:デフォルトの名無しさん
02/09/07 02:32
疎結合から密結合へ退化ですな
75:デフォルトの名無しさん
02/09/07 02:52
UNIXは疎に過ぎる。
パイプとソケットだけではもうまともなアプリは作れないよ。
プロセス・ネット越しにオブジェクト間でお話できないとね。
76:デフォルトの名無しさん
02/09/07 02:59
あのー質問です。gnu make 使っているんですけど
make を起動した後でどこかのディレクトリに潜って(depして)
元のディレクトリの内容を変更したんですが
正しくディレクトリの変更が反映されていないみたいなんです。
元の gmake にもう一度ディレクトリ内のファイルの依存関係を
読み込ませるにはどう指示すべきでしょうか？
77:デフォルトの名無しさん
02/09/07 04:31
>>75
pipe とかの上でも、HTTP とかの protocol を使えば、お話自体はできるはずなんだけど…
誰かがそんな library 作って広めない限り、話しかけても相手にされないんだよね…
PID か何かを元に、それぞれが互いに話しかけたりできればいいんだけど…
78:デフォルトの名無しさん
02/09/07 06:53
PascalのUNIT方式ならメイクに必要な情報はソース中に書いてコンパイラが処理してくれるのに。
C使うとソースとは別にmake書かなきゃならないんで「なんでこれくらいのことやってくれないんだ」とイライラしてくる。
そのくせコンパイル速度も遅いし。
79:デフォルトの名無しさん
02/09/07 12:27
コンパイル速度と言えば、gccってpch (precompiled header)みたいなのないの？
VC++にあるけど、あれがあれば開発中にコンパイル速度に悩むことは無いと思うが。
80:デフォルトの名無しさん
02/09/07 13:24
makefileなんて小規模なのならチョイチョイっとやるだけで済むし、
大規模ならautoconf,automakeで済ませればいいから体した手間ではないと思うのだが…。
81:デフォルトの名無しさん
02/09/07 20:09
>>76
もうちょっと具体的に書いてくれないと答えられないよ。
82:デフォルトの名無しさん
02/09/07 21:58
automakeが面倒なんだが
83:デフォルトの名無しさん
02/09/10 05:00
意外とデフォルトのルールだけでうまくいったりして ...
84:デフォルトの名無しさん
02/09/10 13:02
>>83
> 意外とデフォルトのルールだけでうまくいったりして ...
ライブラリとかあると，なかなかそういうわけにはいかないよね．
85:デフォルトの名無しさん
02/09/10 20:29
検索するとautomake/autoconfサイトいっぱい出てくるんだけど
どのサイトが一番いいの？
86:デフォルトの名無しさん
02/09/10 20:31
あ、そうだ。
死のうっと。
87:デフォルトの名無しさん
02/09/10 20:36
automake win32(非cygwin)で動かしたいんだけど、互換ソフト無いですか？
シェルスクリプトみたいなので、そのままじゃ動かないですよね
88:デフォルトの名無しさん
02/09/10 21:36
>>78
> PascalのUNIT方式ならメイクに必要な情報はソース中に書いてコンパイラが処理してくれるのに。
#if 0
cc -o hoge hoge.c
exit 0;
#endif
#include <stdio.h>
int main(void) { printf("hoge\n"); }
このソースに実行権限をつけて実行するとexit以下は実行せず
かつ#がコメント化する事を利用したハック
コンパイルする場合は#if 0 で囲んであるのでコンパイラは無視する。
ツールレベルの小さなプログラムが多数ある場合、
makefileとソースの管理がウザイんでこの手を使うこともある。
89:デフォルトの名無しさん
02/09/10 23:55
>>78
PascalにUNITなんてものは規定されていない罠。
90:デフォルトの名無しさん
02/09/13 14:08
せめてデフォルトで用意されているマクロくらいは
make 間で統一されてればなーと思いませんか ?
91: ◆k/Ubp.Kg
02/09/13 14:30
>>90
あー、それは確かに思うね。普段はGNU make使ってるから気にならないけど、他のmake使うと途端に困る…w
92:デフォルトの名無しさん
02/09/13 16:40
automakeってヘッダの依存まで調べてくれるの?
93:90
02/09/13 17:09
あと, つい数日前まで恥ずかしながら知らなかったことなんですが,
Solaris 6 (7 かも) の /usr/ccs/bin/make の suffix rule って, 例えば
.c.o : rule っていう感じなんですね.
.c.o :
rule
ではだめみたい. 特定の make に依存しないように, デフォルトのマクロの挙動に
気を使って Makefile を書いてたけど, その努力は意外なところから破綻してしました ...
94:デフォルトの名無しさん
02/09/13 18:28
>>92
> automakeってヘッダの依存まで調べてくれるの?
$ gcc -M hoge.c
で出力される程度には調べてくれます。depcompが調べてくれたと思います。
95:デフォルトの名無しさん
02/09/13 20:49
ちょほいと勉強しようと思ったけど長すぎて読んでられないよ
URLﾘﾝｸ(www.gnu.org)
URLﾘﾝｸ(www.gnu.org)
96:デフォルトの名無しさん
02/09/14 09:01
>>95
> ちょほいと勉強しようと思ったけど長すぎて読んでられないよ
texinfo-4.2を使っているなら、それぞれソースを持ってきて
$ makeinfo --html auto*.texi
すると分割されるが、って、全体の長さは変わらないけどね。
GNUjdoc (URLﾘﾝｸ(openlab.ring.gr.jp))には日本語訳も
あるみたい。
97:デフォルトの名無しさん
02/09/14 13:09
>>75 >>77
Gnomeは単なるGUIシェルだと思ってるのか?
98:デフォルトの名無しさん
02/09/14 22:32
以下のようなディレクトリ構成の場合にちゃんとビルドするには
どうしたらいいでしょうか？gmake か MS の make か borland の make でお願いします。
一応、ディレクトリ分けしない状態ならうまくいった(ボーランドのmake)のですが…
+project
|-------makefile
|-------+bin
| |-------app.exe
|-------+obj
| |-------abc.obj
| |-------def.obj
|-------+src
| |-------abc.cpp
| |-------def.cpp
|-------+include
|-------abc.h
|-------def.h
●ディレクトリ分けしなかった時の makefile
CPP_FLAGS = -c -GX -GR
CPP_COMPILE = cl
LINK = link
OBJS = abc.obj def.obj
app.exe: $(OBJS)
$(LINK) $(OBJS)
.cpp.obj:
$(CPP_COMPILE) $(CPP_FLAGS) $<
.h.cpp:
よろしくお願いします。
99:デフォルトの名無しさん
02/09/14 22:38
お前ら自慢の手書きmakefileのテンプレ晒して下さい。
100:デフォルトの名無しさん
02/09/14 23:24
>>98
なんかmakefile以前の問題のような。
望むような動作をバッチファイルで書ける？
101:98
02/09/14 23:39
>>100
望む動作をバッチファイルで実現できたら make は使いませんが…
普通にコンパイルする方法を知っているのか？という意味だと受け取ったので
「それくらいわかってるよ！」という事を証明しておきます。
cl -c -GX -GR -Fo.\obj\abc.obj .\src\abc.cpp
cl -c -GX -GR -Fo.\obj\def.obj .\src\def.cpp
link -out:.\bin\app.exe .\obj\abc.obj .\obj\def.obj
これを是非 makefile にしたいです。
102:デフォルトの名無しさん
02/09/15 00:05
>>101
makefile :
bin/app.exe:
cl -c -GX -GR -Fo.\obj\abc.obj .\src\abc.cpp
cl -c -GX -GR -Fo.\obj\def.obj .\src\def.cpp
link -out:.\bin\app.exe .\obj\abc.obj .\obj\def.obj
clean:
del /s /q . > nul
rmdir /s /q .
103:デフォルトの名無しさん
02/09/15 00:25
>>98
もっと具体的に書いてくれないとわかんないよ。
104:98
02/09/15 00:28
>>102
いやーお兄さん一本取られちゃったな。
> 望む動作をバッチファイルで実現できたら make は使いませんが…
を優先ですか、さすが！
っていうか、マジレスキボンヌです。
ちゃんと依存関係を調べて make できる makefile の書き方を教えてください。
よろしくお願いします。
105:98
02/09/15 00:31
>>103
src 内に .c や .cpp ファイルがあって、
include 内に .h があって
これらのファイルをコンパイルして
最後にリンクして、できあがったファイルを bin の中に入れたいのです。
よろしくお願いします。
106:デフォルトの名無しさん
02/09/15 01:04
>>99
#
CFLAGS = -ansi
107:デフォルトの名無しさん
02/09/15 01:07
>>105
それだけではどんな統合環境でもメイクできないのでは。
リンクしてできあがるファイルが何なのかさえわからないじゃん。
108:デフォルトの名無しさん
02/09/15 01:11
>>98
暗黙のルールに依存しないで
すべてのソースを明示的にコンパイルすりゃできるけど
そんなの面倒だから全部同じディレクトリにしとけ。
んでmake installでバイナリだけコピーすりゃいいよ。
109:98
02/09/15 01:17
>>107
いや、ファイルの種類や、取り扱いに使うコマンドはどうでもいいのです。
make の書式について知りたいのです。
とりあえず上記例でも出しているのでコマンド等は下記のように仮定してもらっても結構です。
できあがるファイルの種類 *.exe
ソースの種類 *.cpp
ソースが依存しているファイルの種類 *.h
コンパイルに使用するコマンド cl.exe
リンクに使うコマンド link.exe、
コンパイル時に常に引き渡すオプション -c -GX -GR
リンク時に常に引き渡すオプション なし
cl.exe に出力ファイルを指定する為のオプション -Fo
link.exe に出力ファイルを指定する為のオプション -out:
よろしくお願いします。
110:デフォルトの名無しさん
02/09/15 01:19
もう一声.
知りたい make の書式とはどんなやつのこと ?
111:98
02/09/15 01:19
>>108
まともなレスありがとうございます。
暗黙のルールの中にはディレクトリは指定できないという事でしょうか？
112:98
02/09/15 01:22
>>110
えっと…、「書き方」です。
.cpp ファイルが src というディレクトリ内にあって、
.h ファイルが include というディレクトリ内にあって、
.obj ファイルが obj というディレクトリ内にあるんだよ。という事を
make に教える方法というか…。
113:デフォルトの名無しさん
02/09/15 01:24
>>109
手っ取り早いのは vpath でサーチするディレクトリを追加じゃない？
bin に ふつーに Makefile を書いて vpath で include や src を追加したら
それらのディレクトリも見てくれる。
厳密にやりたいなら、スクリプトの助けがいりそう。
おいらは素人なので偉い人ならもっとスマートにできるかもしれないけど。
114:デフォルトの名無しさん
02/09/15 01:28
suffix rule はカレントディレクトリしか検索しないと思います.
で, 113 の言うとおり VPATH で指定すればいいんですけど,
お使いの make にその機能はありますか ?
115:98
02/09/15 01:29
CPP_FLAGS = -c -GX -GR
CPP_COMPILE = cl
LINK = link
>>110
ちなみに、下記は擬似例ですが、雰囲気は伝わるでしょうか？
. が拡張子の意味とカレントディレクトリの意味でかぶっていて見づらいとは思うのですが
>>98, >>112 とあわせて見てもらえると、私が何を求めているのか
理解して頂けるような気がするのですが…
OBJS = ./obj/abc.obj ./obj/def.obj
./bin/app.exe: $(OBJS)
$(LINK) $(OBJS)
./src/.cpp ./obj/.obj:
$(CPP_COMPILE) $(CPP_FLAGS) -fo ./obj/$<.obj ./src/$<
./include/.h ./src/.cpp:
116:98
02/09/15 01:32
失礼しました、上の方に謎な文がくっついてしまいました。
# Mozilla 1.0 ってちょっとバギーですよね…。
# .9.x の頃のがしっかりしてたな…。
>>113-114
無学なもので vpath という物を知らないのですが、
独立したコマンドでしょうか？ make のオプションでしょうか？
117:113
02/09/15 01:33
>>113
具体的に言うと shell でディレクトリに潜って ls でリストを変数にいれて
addprefix で bin/ なり src/ なり include/ obj/ なりを付け加えて
それを Makefile.hogera で出力して $(MAKE) -f Makefile.hogera
ってする。
118:113
02/09/15 01:34
>>116
GNU Make にあるコマンド。addprefix もそう。
119:98
02/09/15 01:36
>>117
なるほど、そういう技巧を使わないとできないんですね。
>>108 さんの方法でお茶を濁そうかと思います。
みなさんありがとうございました。
120:113
02/09/15 01:51
別に技巧ってほどのものじゃないしスマートじゃないけどね…。
やっぱ偉い人がツッコミいれてくれないとイマイチだな…。
121:デフォルトの名無しさん
02/09/15 02:01
make自体スマートじゃないからどうしようもない。
それに凝ったmakefile書く奴ってく非生産的なのが多いので
makefileはシンプルに。つかVC使えよ。
122:デフォルトの名無しさん
02/09/15 02:03
VC厨までが出てきたか もう寝るよ
123:デフォルトの名無しさん
02/09/15 02:21
↑もう起きて来なくていいよ。
124:デフォルトの名無しさん
02/09/15 02:39
>>120
低レベルなム板で頑張っても無意味。unix板に帰ろう。
125:
02/09/15 05:40
>>98
こんなところだろう。
SRCDIR=src
OBJDIR=obj
INCDIR=include
BINDIR=bin
DIRS=$(OBJDIR) $(BINDIR)
CPP_COMPILE=cl
CPP_FLAGS=-c -GX -GR -Fo$(OBJDIR)\ -I$(INCDIR)
LINK=link
LINK_FLAGS=
OBJS=$(OBJDIR)\abc.obj $(OBJDIR)\def.obj
TARGET=$(BINDIR)\app.exe
all: $(DIRS) $(TARGET)
$(DIRS):
@if not exist $@\nul mkdir $@
$(TARGET): $(OBJS)
$(LINK) -out:$@ $(LINK_FLAGS) $(OBJS)
{$(SRCDIR)\}.cpp{$(OBJDIR)\}.obj:
$(CPP_COMPILE) $(CPP_FLAGS) -c $<
$(OBJDIR)\abc.obj: $(INCDIR)\abc.h
$(OBJDIR)\def.obj: $(INCDIR)\def.h
126:デフォルトの名無しさん
02/09/15 06:33
>>125
>$(LINK) -out:$@ $(LINK_FLAGS) $(OBJS)
-out:が思いっきり依存しちゃってるので、CPP_COMPILEとか定義する意味がない
>$(OBJDIR)\abc.obj: $(INCDIR)\abc.h
>$(OBJDIR)\def.obj: $(INCDIR)\def.h
これがかなりｲﾏｲﾁと感じる。
127:デフォルトの名無しさん
02/09/15 12:04
>>125
その Makefile まともに動かないような気がするんですが,
MS か Borland の make ではちゃんと動くんですか ?
GNU make では意図したとおりに動かないですよねえ ...
気のせいかな.
128:デフォルトの名無しさん
02/09/15 14:33
ほれ。検証しとらんがこんなもんだろ。gmake 版ね。
BINDIR = bin
OBJDIR = obj
SRCDIR = src
INCDIR = include
COMPILER = cl
TARGET = $(BINDIR)/app.exe
OBJS = $(addprefix $(OBJDIR)/, abc.obj def.obj)
all: $(TARGET)
$(TARGET): $(OBJS)
<TAB> $(COMPILER) $(LDFLAGS) $^ -o $@
$(OBJDIR)/%.obj: $(SRCDIR)/%.cpp
<TAB> $(COMPILER) $(CFLAGS) -c $< -o $@
129:デフォルトの名無しさん
02/09/15 15:07
>>128
検証しました。
makefile 的にはあっている模様ですが、当方の cl.exe (VC6SP5)が
-c オプション(コンパイルオンリー) を指定した場合、
-o でディレクトリを指定しても無視されて、全部カレントに吐き出す為
だめぽになっています。
あと
TOUCH = touch
で
$(SRCDIR)/%.cpp: $(INCDIR)/%.h
<タブ> $(TOUCH) $@
は書き忘れでしょうかね。
130:デフォルトの名無しさん
02/09/15 15:24
なるほど pattern rule は suffix rule と違って, ディレクトリ指定が
できるのがいいですね. いままで使用する make にかなり依存するので避けてたんですが.
ちなみに Linux の GNU make, Solaris の make では OK,
IRIX, FreeBSD の make ではだめでした.
131:129
02/09/15 15:28
ちゃうわ、cl.exe の出力ファイル指定オプションは -Fo やった。
これで VC + gmake 使いの皆さんはハッピーになれますか？
BINDIR = bin
OBJDIR = obj
SRCDIR = src
INCDIR = include
COMPILER = cl
TOUCH = touch
TARGET = $(BINDIR)/app.exe
OBJS = $(addprefix $(OBJDIR)/, abc.obj def.obj)
all: $(TARGET)
$(TARGET): $(OBJS)
<豚>$(COMPILER) $(LDFLAGS) $^ -o $@
$(OBJDIR)/%.obj: $(SRCDIR)/%.cpp
<豚>$(COMPILER) $(CFLAGS) -c $< -Fo./$@
$(SRCDIR)/%.cpp: $(INCDIR)/%.h
<豚>$(TOUCH) $@
132:デフォルトの名無しさん
02/09/15 15:36
>>130
> IRIX, FreeBSD の make ではだめでした.
gmake は入ってませんか? なけりゃインストールしちゃいましょう。
わたしゃ、もう、gmake 以外は使えない体になってしまいますた。
>>131
> $(SRCDIR)/%.cpp: $(INCDIR)/%.h
> <豚>$(TOUCH) $@
あまり見かけないやりかたですね。cl には gcc の -M オプションみたいのは
ないのかな?
133:デフォルトの名無しさん
02/09/15 15:54
makedepend.exe っつーのが存在するようですね。
URLﾘﾝｸ(www.google.com)
134:デフォルトの名無しさん
02/09/15 21:12
cygwin を使っているのですが、makefile 中で
cd Dir
pwd
と書いたとき、pwd が Dir に移動していない時のディレクトリを返してきます。
これは通常動作なのでしょうか？
135:デフォルトの名無しさん
02/09/15 21:17
通常動作。各行は、(おそらく) system によって実行されている。
136:デフォルトの名無しさん
02/09/15 21:20
通常動作です.
make は 1 行ごとにコマンド行を解釈して shell を呼び出すような
動作をします.
hoge : fuga
<tab>cd Dir; \
<tab>pwd
でお望みの動作が得られると思います.
137:134
02/09/15 22:37
>>135-136
なるほど、各行で独立して実行されるイメージなのですね。
ありがとうございました。
138:デフォルトの名無しさん
02/09/16 03:32
Makefile中でヒアドキュメントを使えますか？
cat <<EOF
any message
EOF
ってのをMakefileでやりたいのですが、tabをいれたりとかいろいろやってもうまくいきませんでした。
1行ずつechoするしかないんでしょうか。
139:デフォルトの名無しさん
02/09/16 04:06
\
140:デフォルトの名無しさん
02/09/16 05:39
>>139
それがうまくいかないんです。多分使い方が間違っていると思うんですけど。
target:
[TAB]cat <<EOF \
[TAB] hoge hoge \
[TAB]EOF
target:
[TAB]cat <<EOF
[TAB] hoge hoge \
[TAB]EOF
こんなのは試しました。
141:デフォルトの名無しさん
02/09/16 05:46
depend:
makedepend -- $(FLAGS) -- $(ALL_C_FILES)
142:デフォルトの名無しさん
02/09/16 10:10
ヒアドキュメントはあまり使わないので詳しくないのですが.
もし sh 上で 1 行でヒアドキュメントが使えれば, make でも使えるかも
しれません ... が, 私にはできないように思います.
143:デフォルトの名無しさん
02/09/16 18:10
<<EOFが不要なんじゃ
target:
[TAB]cat \
[TAB] hoge hoge
144:
02/09/16 19:03
>>143
here documentって知ってる？
145:デフォルトの名無しさん
02/09/18 12:30
>>140
\ → ;\
は試した？
146:138
02/09/20 02:59
>>145
返事が遅れてゴメンなさい。
all:
[TAB]cat <<EOF;\
[TAB]hoge hoge \
[TAB]EOF
として試してみましたが、
/bin/sh: hoge: command not found
と出ました。
# 仕方無いのでechoで頑張りますた。
147:デフォルトの名無しさん
02/10/22 21:22
Eiffel イイ!!
148:デフォルトの名無しさん
02/10/22 21:43
あげちゃったわけでつか。
あげちゃったわけでつか。
あげちゃったわけでつか。
あげちゃったわけでつか。
あげちゃったわけでつか。
あげちゃったわけでつか。
あげちゃったわけでつか。
あげちゃったわけでつか。
氏ねよ、クソが。
149:デフォルトの名無しさん
02/10/22 21:56
>>1
ant
150:デフォルトの名無しさん
02/10/23 16:26
下のコメントのようなことがしたくて悩んでいるんですが、
どうすればいいでしょうか？ お知恵を貸してください
DATAFILES1 = a.dat b.dat
DATAFILES2 = c.dat d.dat
OFILES = $(DATAFILES1:.dat=.o) $(DATAFILES2:.dat=.o)
%.o : %.dat
# DATAFILE1のファイルは, objcopy -XXXX $< $@
# DATAFILE2のファイルは, objcopy -YYYY $< $@
151:デフォルトの名無しさん
02/10/23 17:36
OFILES1 = $(DATAFILES1:.dat=.o)
OFILES2 = $(DATAFILES2:.dat=.o)
# DATAFILE1のファイルは, objcopy -XXXX $< $@
$(OFILES1): %.o : %.dat
objcopy -XXXX $< $@
# DATAFILE2のファイルは, objcopy -YYYY $< $@
$(OFILES2): %.o : %.dat
objcopy -YYYY $< $@
152:150
02/10/23 19:52
>>151
そんな記述ができるんですね。
すごく勉強になります。
ありがとうございます。
153:デフォルトの名無しさん
02/10/24 04:43
>>151
それ知らなかった。info make見ても見つけられなかったんだが、どこに書い
てある?
154:デフォルトの名無しさん
02/10/24 10:10
static pattern rules のところに書いて歩けど。
155:デフォルトの名無しさん
02/10/24 10:11
あ、もちろん GNU Make の話ね。
156:デフォルトの名無しさん
02/10/24 11:42
>>154
ほんとだ。tnx
ふしあなさんだったよ。
157:デフォルトの名無しさん
02/11/05 00:28
HSP使えばいいのに
158:デフォルトの名無しさん
02/11/12 11:43
VB のためなら死ねる!!
159:デフォルトの名無しさん
02/11/22 20:59
static pattern rules のところに書いて歩けど。
160:みな
02/11/25 15:20
■『C と C++ とが混在した Makefile で makedepend を使うには？』[1/2]
初めまして。宜しく御願い致します。
まず，私は Makefile に関してはかなり未熟者のレベルです。
必要に応じてウェブ上で検索しては知識を付けている段階です。
さて，止むを得ない事情で，
*.h *.c *.cpp という，C と C++ とが混在した Makefile でプログラム開発中です。
makedepend を導入したいと思い，
ウェブ上で検索した幾つかの入門ページを参考にしつつ，―
TOP = /usr/local/test
INCDIR = $(TOP)/../common/include -I$(TOP)/include
SRCS = aaa.c bbb.c
SRCSXX = xxx.cpp yyy.cpp
OBJS = $(SRCS:.c=.o)
OBJSXX = $(SRCSXX:.cpp=.o)
CFLAGS = -O3 -Wa,-al -fno-common -G0
CXXFLAGS = -O3 -Wall -Werror -Wa,-al -fno-exceptions -fno-common -G0 -ansi
.SUFFIXES: .o .s .dsm .c .cc .cpp
depend:
makedepend -I$(INCDIR) -- $(CFLAGS) -- $(SRCS) 2>/dev/null
makedepend -a -I$(INCDIR) -- $(CXXFLAGS2) -- $(SRCSXX) 2>/dev/null
―（一部抜粋 & ファイル名は例示用）の様に Makefile を書き直し，
途中までは意外と（？）順調に導入が進んだのですが…。
（▼ >>161 に続く…… ▼）
161:デフォルトの名無しさん
02/11/25 15:21
make!
162:みな
02/11/25 15:28
■『C と C++ とが混在した Makefile で makedepend を使うには？』[2/2]
（▲ …… >>160 からの続き ▲）
（※ 先に >>161 に割り込まれてしまいました…。スミマセン…。）
やっと，導入完了と思って make depend と実行してみたところ，
Makefile 中には―
# DO NOT DELETE
aaa.o: def4c.h aaa.h
bbb.o: def4c.h bbb.h
xxx.c.o: def4cpp.h xxx.h
yyy.c.o: def4cpp.h yyy.h
―の様に自動生成されてしまいました。
勿論，正しくは―
# DO NOT DELETE
aaa.o: def4c.h aaa.h
bbb.o: def4c.h bbb.h
xxx.o: def4cpp.h xxx.h
yyy.o: def4cpp.h yyy.h
―となって欲しいところなのですが，
ウェブ上で検索して出てくる典型的なサンプルは *.c しか前提にしてない様で，
一体どうやれば良いのかさっぱりわかりません。
もしかして，makedepend 自体が C++ には対応してないのでしょうか…？
どうぞ御教授下さい。
正解そのものが無理なら，より適切な調べ方（検索方法）だけでも，御願い致します。
※ 以上で情報不足の場合は，
例えば Makefile の一部抜粋等々，今後追加書き込み致します。
163:デフォルトの名無しさん
02/11/25 16:48
使ってる makedepend が腐ってるんじゃないのかなぁ?
1) 新しいやつをインストールしてみるか
2) gcc/g++ -MM オブションを使うか
3) | sed -e 's/\.c\.o/\.o/' をかますか
してみては。
164:みな
02/11/25 17:59
>>163 さん，早速レス有り難う御座います。
周りの人に訊いても，自力で色々検索しても，サッパリわかんなかったんで，
こうして何かレス頂けると，ホント嬉しいです。
makedepend が腐ってるっスか…。う〜ん…。
man 見ても，makedepend のバージョン表示する為のオプションって
見当たらないですよねぇ。（困）
えぇと…，取り敢えず「3) | sed -e 's/\.c\.o/\.o/' をかます」って，
具体的にどこにどう記述すればいいんでしょうか？
165:かなり適当
02/11/25 18:33
>>160
> .SUFFIXES: .o .s .dsm .c .cc .cpp
この行消してみるとどうなる？
166:みな
02/11/25 19:04
「かなり適当」こと >>165 さん，只今やってみましたが―
―やっぱりダメでした…。
自動生成内容に，何も変化は起こりませんでした。
そういえば，自分で試行錯誤してた際も，この行を色々と書き換えてみたけど，
結果に何等変化が無かった記憶が…。
てゆーか，そもそもこの行，そんなに必要な行なんですかねぇ…？？
一応，サンプルなぞを真似つつ，取り敢えず付けてあるだけな感じなんですけど。
仮に全く無くしたりすると，具体的にどんな不都合が…？
167:163
02/11/25 19:14
そうか、makedepend って、Makefile を直接書き換えちゃうのか。
とすると、makedepend をした後に、
sed -e 's/\.c\.o/\.o/' Makefile > Makefile.new
mv Makefile Makefile.bak
mv Makefile.new Makefile
とかやってみては。
ちなみに、オレだったら、GNUMakeが前提だけど
depend:
makedepend -fdepend.mf -I$(INCDIR) -- $(CFLAGS) -- $(SRCS)
makedepend -f- -I$(INCDIR) -- $(CXXFLAGS2) -- $(SRCSXX) | sed 's/\.c\.o/\.o/' >> depend.mf
-include depend.mf
とやるかな。つまり、依存関係は別ファイルに書き出して、それを
Makefile にインクルードさせる。
168:みな
02/11/25 19:40
度々アドバイス有り難う御座います。＞ >>163（＝ >>167）さん
いや，>>163 で書いてあった「3)」の，（パイプで）「かます」っていうのが，
Makefile 中のどこにどんな風に記述したらいいのか謎だったんです。
取り敢えず，>>167 前半のやり方で，一応目的の内容の Makefile は得られますね。
もしかしたら，もっとスマートなやり方が有るのかも知れませんけど。
（コマンドライン複数行分を何等かのスクリプトファイルにしちゃうとか…？）
>>167 後半のやり方は，今から早速勉強させて頂きます。
某 Visual 何たらの統合環境の“全自動”に甘やかされて育つと，
いざという時に弱々だなーと，思い知らされてるトコでして…。
今回は，色々と教えて下さって，有り難う御座います。
もしかしたら，今後また別件でマヌケな質問してしまうかも知れませんけど。（汗）
169:デフォルトの名無しさん
02/11/26 12:25
普通のmakeだったら.dependってファイルに依存関係吐き出しとけば
勝手に読み込んだりしないかな？FreeBSDのmakeはそうだったけど。
.dependをつくるmkdepなんてコマンドもある。
-aオプションをつけると追加書き込みもしてくれるみたい。
170:デフォルトの名無しさん
02/11/26 14:17
どこのmakedependだか知らないけど、Xに付いてるやつなら、
大昔からC++には対応しているはずだけどなあ。
どうせそんなmakedependなら、sedで逃げても、まともに
C++の構文読んでくれなかったり、__cplusplusが定義されて
いなかったりするんじゃないのか？
まともなmakedepend入れた方がいいよ。
gccmakedepなら-MMとか使えるし。
171:名無しさん＠カラアゲうまうま
02/11/26 14:30
>>169
たぶん*BSD固有。
172:みな
02/11/26 17:15
>>170 さん
gccmakedep なんて在ったんですね。知りませんでした…。
で，>>160 の makedepend を単に gccmakedep に置換してみたところ，
あっさり，*.c.o の問題は解決しました！
まずは，有り難う御座います。＞ >>170 さん
ところが，別の問題が…。
makedepend の生成してくれた依存関係は，
ホントに漏れ無く書き出してある感じだったんですけど，
gccmakedep の生成してくれる依存関係は，
パッと見ただけで，明らかに不足気味なんですよ。
例えば，何十個も在るソースファイル中に，
test1.cpp test2.cpp test3.cpp というのが在ったとすると，
当然，test1.o test2.o test3.o それぞれに
依存関係の在るヘッダファイル *.h を書き出してあるべきですけど，
gccmakedep の生成する依存関係って，
例えば test1.o と test3.o とに関しては書き出してあっても
なぜか test2.o に関しては何も書き出してなかったりとか。
勿論，test2.cpp から何も #include してないなんて事はありません。
う〜ん，まさに一難去ってまた一難。
173:デフォルトの名無しさん
02/11/26 22:17
ifdefの関係でincludeされないようになっているとか。
-DXXXは基本的にコンパイル時と同じように設定しないとダメ。
あと、インクルードパスが通っていないのかも。多分C++の
標準インクルードパス(/usr/include/g++とか)は自分で追加
する必要があると思う。
それでダメなら、根本的に環境がおかしいのかなあ。gccmakedep
が入っているからにはXが入っているんだろうけど、X11R5だったり、
gccがegcsよりさらに昔のだったりしないか？あるいは、gcc向け
でなく、別のコンパイラ向けにソースを書いているのに、gccmakedep
を使おうとしているとか。
174:みな
02/11/27 13:46
>>173 さん
前半で御指摘の「includeされない」「パスが通っていない」云々は，
まず無いと思うのですけど…。
理由は，>>172 に書いた通り，
「>>160 の makedepend を単に gccmakedep に置換してみた」だけだからです。
つまり，makedepend の方を使えば，当初の謎だった「*.c.o の問題」以外は，
全てうまくいってました。
また，もし #ifdef がらみで #include されてなかったとすると，
宣言無しで暗黙に使おうとした云々と，コンパイル時にエラーが出ると思います。
やはり後半で御指摘の「根本的に環境がおかしい」んですかねぇ…。（困）
OS は RedHatLinux 7.1，コンパイラは GNUC 2.96（＝ GNUC++ 2.96），
makedepend も gccmakedep も /usr/X11R6/bin/ というパスに在ります。
175:デフォルトの名無しさん
02/11/27 17:49
じゃあ、処理速度は遅くなるけど、gcc/g++ の -M(または-MM)オプションを
使ってみたらどうかな。こいつは依存関係を標準出力に出すので、
リダイレクトしてファイルに落とす。そして、>>167 みたいに
-include でインクルードしてやればよい。Linux ということは gmake を
使ってるわけだよね?
176:デフォルトの名無しさん
02/11/27 18:03
>>174
> やはり後半で御指摘の「根本的に環境がおかしい」んですかねぇ…。（困）
> OS は RedHatLinux 7.1，コンパイラは GNUC 2.96（＝ GNUC++ 2.96），
> makedepend も gccmakedep も /usr/X11R6/bin/ というパスに在ります。
rpm -qf /usr/X11R6/bin/{makedepend,gccmakedep}
の結果は?
177:みな
02/11/27 18:39
>>175 さん
私も，>>167 さんが後半で書かれてた方法が一番良さそうに思えたんで，
gcc の man とか色んな関連ウェブページとか見ながら，習得中です。
（スミマセン。発展途上なもんでして…。）
ちなみに，make も gmake も /usr/bin/ というパスに在って，
使ってるのは一応 gmake の方なんですけど，試しに make の方に変えてみても，
（少なくとも気付いた範囲内では）結果は何も変わらない様です。
>>176 さん
rpm -qf /usr/X11R6/bin/{makedepend,gccmakedep} してみたら，―
XFree86-devel-4.0.3-5
XFree86-devel-4.0.3-5
―と出てきました。
ゴメンナサイ。rpm というモノ自体，>>176 を読んで今初めて知った次第で…。（汗
なるほど，「rpm is a powerful package manager」ですか。
でも，その前に使う人が powerful に成長しないと，宝の持ち腐れですね…。（自嘲
178:176
02/11/27 19:04
>>177
> XFree86-devel-4.0.3-5
もう4.2.1とか出てるのでバージョンを上げてみては。
全部上げるのがいやなら、
rpm -Uvh --excludepath /usr/X11R6/lib --excludepath /usr/X11R6/include \
--excludepath /usr/X11R6/man ${XFree86develRPM}
とか、
cd /
rpm2cpio ${XFree86develRPM} | cpio -i usr/X11R6/bin/{makedepend,gccmakedep}
とか。
179:デフォルトの名無しさん
02/11/28 00:42
URLﾘﾝｸ(happysize.com)
↑こんなんもあるぜ。
漏れはソースを俺様カスタマイズしてつかってるぜ。
180:みな
02/11/28 14:08
>>178 さん
[mina@localhost mina]$ rpm -Uvh --excludepath /usr/X11R6/lib --excludepath /usr/X11R6/include --excludepath /usr/X11R6/man ${XFree86develRPM}
rpm: インストールのためのパッケージがありません
[mina@localhost mina]$ cd /
[mina@localhost /]$ rpm2cpio ${XFree86develRPM} | cpio -i usr/X11R6/bin/{makedepend,gccmakedep}
error: read failed: Success (0)
error reading header from package
cpio: premature end of archive
[mina@localhost /]$
―な感じでした。だめぽ…？
いや，そもそもシス管に訊けとかインストールした人に頼めとか，
心中でツッコみながら私の書き込み読んでる方々も少なくないと思うんですけど，
この環境構築した人自体が，雑誌とか入門書とかと首っ引きで何とか構築したとゆー，
ある意味“発展途上”な人なもんで…。（勿論，私よりは“上”ですけど。）
>>164 で「周りの人に訊いても―（中略）―サッパリわかんなかったんで」
と書いたのは，そんな訳だったんです。（類は友を呼ぶ…？）
181:みな
02/11/28 14:08
>>179 さん
あっ，その "autodep" って，色々 Google 検索してた中で見た記憶が…。
リンク先あちこち紫色になってるし。
コレって，一企業（株式会社ハッピーサイズ）が御厚意で無償提供して下さってる，
一フリーソフトですよね？
ですから，あまり標準的・一般的じゃないユニークなモノに
最初っから頼りきっちゃうと，後々何かマズいかなーとか，
（折角習熟してもツブシが利かないとか…？）
何と無く思ってしまって，初めて見た時はそのまま流してしまってました。
やっぱ，いいですか。"autodep"。
後でダウンロードして，ちょっと試してみますね。
情報，有り難う御座います。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5375日前に更新/188 KB
担当:undef