Autoconf,Automakeについて

1 名前：名無しさん＠お腹いっぱい。 [02/04/11 05:24.net] 奥深さの前に使い方がさっぱり分からん。教えて下さい。 関連サイトは>>2 13 名前：名無しさん＠お腹いっぱい。 mailto:sage [02/04/13 23:51.net] >>12 (ﾟДﾟ)ﾊｧ? 14 名前：名無しさん＠お腹いっぱい。 mailto:sage [02/04/14 01:18.net] なんかこの板最近殺伐としてきたな。喜ぶべきことかどうなんだろうか･･･ 15 名前：名無しさん＠お腹いっぱい。 [02/04/14 10:33.net] >11 いつのまにcross buildの機能が付いたね。FreeBSD的には有難い。 しかし、そんなこと知らずに偽cpp作ってゴリゴリhost.defとか書た 苦労はいったい・・・ 16 名前：名無しさん＠お腹いっぱい。 [02/04/14 11:03.net] autoconf、automakeのスレ、荒れてる。 もったいないよ、盛り上げようよ。 17 名前：名無しさん＠お腹いっぱい。 mailto:sage [02/04/14 11:24.net] 何もわかってない馬鹿が暴れてるんだろうな >>8 >>12 18 名前：名無しさん＠お腹いっぱい。 [02/04/14 12:03.net] configure.inを書かずにGPLで配布することは恥かしいことなんですか？（ｗ 19 名前：名無しさん＠お腹いっぱい。 mailto:sage [02/04/14 13:42.net] >>18 configure.in configure.acを利用しない方が恥ずかしい罠。 20 名前：名無しさん＠お腹いっぱい。 mailto:sage [02/04/14 16:28.net] どーでもいいけど板違いな気がするんですが 21 名前：9 mailto:sage [02/04/14 19:44.net] >>10 autoconf は OS 間の非互換性を補う使い方に留めてほしい。 自分がリンクしたいライブラリが無かった時、勝手に WITHOUT_LIBHOGE みたいなオプションを付けてそれ抜きでコンパイルするのは嬉しくない。 そのライブラリを使うか使わないかはユーザが決める事柄なんだから、 --with-libhoge とも --withoug-libhoge とも指定してないのに、勝手に WITHOUT_HOGE とかして欲しくない。 黙ってコンパイルして、黙ってリンカエラーを出してくれればそれでいい。 事前に親切に「libhoge ねえぞ、入れろやｺﾞﾙｧ」と言ってくれれば便利だが、 そこまでは求めない。 あと、OS 標準じゃない物を探すんだったら /usr/lib と /usr/include 以外の場所も適宜探してくれないと不便だと思う。何でも /usr 直下に 突っ込むことを暗黙の前提としているのではないか。 22 名前：10 mailto:sage [02/04/14 21:29.net] 了解。勘違いしていた。 >>21 > 自分がリンクしたいライブラリが無かった時、勝手に WITHOUT_LIBHOGE > みたいなオプションを付けてそれ抜きでコンパイルするのは嬉しくない。 これは同感です。 # というより、Autoconfの使い方が悪い。 > 黙ってコンパイルして、黙ってリンカエラーを出してくれればそれでいい。 これやっちゃうと、バグの報告が大量に発生すると思うので、マトモなパッ ケージなら、 > 事前に親切に「libhoge ねえぞ、入れろやｺﾞﾙｧ」 と言ってくれると思うんですがどうでしょう。 # マトモの定義の話は無しね。 多分、Makefileを適切に書くのが面倒だから「Automake Autoconfでパッケー ジ作りました」ってのが多いんだと思う。AC_CHECK_XXXの引数できちんとエラー 処理すれば大丈夫でしょ。 > あと、OS 標準じゃない物を探すんだったら /usr/lib と /usr/include > 以外の場所も適宜探してくれないと不便だと思う。 ライブラリについてはリンクを実際に行なって調査するので、ユーザが環境変 数を設定することで何とかなりますし、ヘッダの方もコンパイル可能かどうか を調査するので同じことではないでしょうか？ ま、言いたいのは、道具はいいけど使い方は人それぞれってことです。 23 名前：名無しさん＠お腹いっぱい。 [02/05/07 06:43.net] age 24 名前：名無しさん＠お腹いっぱい。 [02/05/09 13:38.net] 関係ないんだけど、いいですか？ UNIXの人はWindowsでプログラミングするときは nmakeとcygwin(gmake)のどっち使ってますか？ nmake使いづらいです。。 25 名前：名無しさん＠お腹いっぱい。 mailto:sage [02/05/09 15:02.net] >>24 nmakeってことはVC++？ だったらmsdev使うけど。 26 名前：名無しさん＠お腹いっぱい。 mailto:sage [02/05/09 15:22.net] >>25 vs持ってないもんで、、 27 名前：名無しさん＠お腹いっぱい。 mailto:sage [02/05/09 17:23.net] >26 バカヤロウ。ここはUNIX板。 Windowsはcygwinを入れて使うもんだろ。 コンパイラまでgnuを使うわけにはいかないことも あるが、それ以外は当然全てgnu！ 28 名前：名無しさん＠お腹いっぱい。 mailto:sage [02/06/14 18:43.net] Automake 1.6.2 released sageですが ;-) 29 名前：名無しさん＠お腹いっぱい。 mailto:age [02/07/08 21:37.net] JavaプログラムをAutoconf/Automakeに対応させるにはどうしたらいいのかな? 最低限 make と make install と make dist を使えるようにしたいのだけど。 で、 --- Makefile.am --- bin_PROGRAMS = hello.jar hello_jar_SOURCES = Main.java -- configure.in -- AC_INIT(Main.java) AM_INIT_AUTOMAKE(hello, 1.0.0) AC_ARG_PROGRAM AC_PROG_INSTALL AC_PROG_CC AC_OUTPUT(Makefile) とかやってみたけど当前のように正しいMakefileは出来ないし。 30 名前：名無しさん＠お腹いっぱい。 mailto:sage [02/07/08 22:40.net] >>29 > JavaプログラムをAutoconf/Automakeに対応させるにはどうしたらいいのかな? > 最低限 make と make install と make dist を使えるようにしたいのだけど。 Automake-1.6.2とAutoconf-2.53だと、gcjを利用したコンパイルができるみたい。 でも、うちはJAVAの環境が無いから試せないです。 automakeのinfoの、ノード"Java Support"を参照してみてください。 31 名前：29 mailto:sage [02/07/08 23:37.net] >>30 gcjを入れてみたけどlibgcj.specが????とか出て動かない。かなり険しそう(w とりあえずAutomake-1.4のinfoで'_JAVA'がどうのこうのって記述を見つけたので、 javacで動くように試してみます。 32 名前：名無しさん＠お腹いっぱい。 mailto:sage [02/07/09 00:18.net] >>31 > とりあえずAutomake-1.4のinfoで'_JAVA'がどうのこうのって記述を見つけたので、 > javacで動くように試してみます。 1.4のやつって、javacでのコンパイルのみのサポートだったと思います。 # 記憶が曖昧ですみません。 info にもありますけど、.javaと.classのサフィックスルールを自動的に作れ ない(ファイルの中からクラス名を調査する必要がある)のでそのような仕様だっ たと思います。だからmakeはできてもmake installは難しいと思います。 # でもうまくいったら教えてください。 33 名前：名無しさん＠お腹いっぱい。 mailto:sage [02/07/21 10:19.net] Autoconf-2.53b 開発版リリース（結構前だけど） どーでもいいけど、autoconf-mode.elとかautotest-mode.elとかあるのね。 色が変わるだけみたいだけど。 34 名前：名無しさん＠お腹いっぱい。 mailto:sage [02/10/02 22:22.net] 知らない間にac-2.54 am-1.7になってたのね。 amのdrilistって便利そうなんだけど使っている人いる？ --confiugre=$HOMEしている人ぐらいなのかな。 # ム板のmmmpスレのほうが活発かな？ 35 名前：名無しさん＠お腹いっぱい。 mailto:sage [02/10/27 01:33.net] 36 名前：名無しさん＠お腹いっぱい。 mailto:sage [02/12/17 00:13.net] 保守 37 名前：山崎渉 mailto:（＾＾）sage [03/01/15 13:25.net] （＾＾） 38 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/02/01 12:17.net] autoconfは便利なんだけど、これに対応するようになってから ソースの見通しが悪くなった。 39 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/02/01 21:24.net] 前は環境依存部分を別関数にしたりしてたけど、最近は面倒だからやめた。 確かに見通しは悪くなった。GNUのソースも見るのが辛くなってきた。 # なんか愚痴ばっかりだな。 40 名前：名無しさん＠お腹いっぱい。 mailto:hoge [03/02/07 11:03.net] この前からCommon Lispで書かれた数式処理ソフトウェアの構成を 追ってみようとしてるんだけど、main関数のないLispソースを autotoolsでビルドする構成になってるので、さっぱり分からない。 Autotoolsを使うときには、想定しているコンパイラ・ライブラリの組み合わせと 依存関係を簡単にドキュメント化してくれないと困ってしまう。 逆に移植などがし辛くなってしまうよ。 41 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/02/07 18:55.net] >>40 とりあえずconfigureしてlog見るんじゃだめなの？ Common Lisp知らないからいい加減なこといっているけど。 42 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/02/10 18:50.net] コンパイル型言語じゃないからね、Lispの「メモリダンプ」とかって独特なんです。 で、どんなコマンドが実行されてるんだか （というか、山ほど実行されてるコマンドのうちどれが重要なのか）分からない。 43 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/02/10 21:21.net] いろいろ大変なんですね。LispはEmacsのしか知らないし、 AM_PATH_LISPDIR使っているものしか見たこと無いんで、 役に立たずですまんです。 # autoconfにもLispファイルがあります。 44 名前：名無しさん＠お腹いっぱい。 mailto:age [03/03/19 10:04.net] Autoconf,Automake,Libtoolを解説してる本って少ないながらも一応あるようですけど， どんなもんでしょう？いい本なのでしょうか？ 45 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/03/19 20:26.net] 多分あの本だと思いますがいい本です。ただし、最新のAutoconf、Automakeを 利用するとちょっと戸惑うかもしれません。セレンディップのGNOMEプログラ ミングという本にもこれらの解説があります。 46 名前：名無しさん＠お腹いっぱい。 [03/03/19 22:57.net] オーム社の本の事ですか？ 47 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/03/19 23:47.net] >>46 そうだと思う。 んでも、少々高いから、漏れは立ち読みで逝こうかとｗ 48 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/03/19 23:59.net] やっぱりm4マクロの勉強からかな 49 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/03/28 06:27.net] >>48 勉強ってほどのもんでもない。 50 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/04/04 19:56.net] ２割、３割はあたりまえ。 51 名前：山崎渉 mailto:（＾＾） [03/04/17 12:14.net] （＾＾） 52 名前：あぼーん mailto:あぼーん [あぼーん.net] あぼーん 53 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/05/15 03:41.net] CVSにconfigureまで突っ込んでるプロジェクトもたまに ありますが、ふつうはどこまで含めるものなんですか。 54 名前：名無しさん＠お腹いっぱい。 [03/05/15 14:14.net] FreeBSD PORTS なんかだと、 autoconf{,213,254,257} や automake{,14,16,17} や libtool{,13,14} のように、 古いバージョンも後生大事に用意されていますよね。 これは何故なんでしょうか？ 何か後方互換性に大きな問題でもあるのでしょうか？ 55 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/05/15 16:23.net] はい。 56 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/05/15 16:35.net] >>55 なるほど。 そうだとして、この場合はそれぞれこのバージョンを使えば良い/いけない、 といった判断は一般にどのような基準に基づいて行えば良いのでしょうか？ 57 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/05/15 17:36.net] >56 違うバージョンを使うと動かないので悩む必要はありません。 58 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/05/15 19:54.net] >>57 う〜ん、やっぱり良くわからないです。 とどのつまり、知りたいのは、 PORTS や package のような仕組みの無い OS に automake や autoconf を入れる場合、 とりあえずそれぞれ最新のバージョンのを入れておけば問題ないものなんでしょうか？ それとも、古いバージョンのも入れておいた方が良いのでしょうか？ 59 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/05/15 19:59.net] >>53 configure.acまでと言いたいが、今のAutotoolsのバージョン間の互換性から、 configureまで入れておいたほうが無難。誰でもcheckoutできるプロジェクト なら、「autoconfを実行するとエラーが出ます」というレポートが大量発生す る可能性が高い。しかし、confugure.acやMakefile.amを書き換えると同じ状 況になるんだよね。 AM_INIT_AUTOMAKE([1.7])とかAC_PREREQ(2.57)とか書けばいいのかな？ 60 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/05/15 20:06.net] >>58 Autotoolsを自分のプロジェクトで使うのなら、最新を入れて問題ないです。 他のプロジェクトに参加するなら、そのプロジェクトが推奨するバージョンが あります。適当にソース持ってきて自分でソースなどを修正する時は、そのソー スを書いた人が使っているものと同じバージョンがないとうまく動かないこと もあります。更に、これらのツールは同じprefixにインストールしないとうま く動かない場合が多いです。 私は、$HOME以下のディレクトリにいろんなバージョンが入っているのですが、 libtoolだけはいい方法が見つからないです。 61 名前：>>53 mailto:sage [03/05/16 01:00.net] >>59 さんくす。内輪のプロジェクトなんでconfigure.acまでにしときます。 すでにautotoolsの互換性に悩んでるんだけど、最新版推奨で行くことにします。 configureはtarballに入れればいいし。 62 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/05/16 02:39.net] >>60 どうもです。 私はとくに他人のプロジェクトに参加したりということもなさそうですので、 最新のを入れて問題なさそうですね。 63 名前：名無しさん＠お腹いっぱい。 [03/05/17 02:40.net] とあるソフトの configure.in、 AC_SEARCH_LIBS(tputs, ncurses termcap, HAVE_TERMCAPとdefine, ダメです) みたいなライブラリチェックしかなくてSolaris8上でのconfigureが不能です。 対症療法よりもその辺全面的に書き換えようと思うんで、 configure.in での termcap, curses, ncursesのチェックのお手本になるソフト探してます。 readlineをリンクすることも可能で、Solarisでconfigure;make 可能なソフト、 なんかないでしょうか？gdb? 64 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/05/17 11:11.net] >>63 GNU texinfoが、tercap、ncurses、readlineなどを使ってるみたいです。 infoコマンドのソースはgdbより少ないかな？ 65 名前：63 mailto:sage [03/05/17 18:27.net] >>64 情報ありがとうございます。当たってみます。 66 名前：名無しさん＠お腹いっぱい。 [03/05/19 21:08.net] 済みません、ちょとお邪魔させてください。 事情により初めてautoconf/automake使い始めたとこなんですが、 unyalib--------------------subDirA 　　ソ ースいくつか　　　|　　　　　　　ソースいくつか 　　　　　　　　　　　　　　　| 　　　　　　　　　　　　　　　| 　　　　　　　　　　　　　　　|-----subDirB 　　　　　　　　　　　　　　　　　　　　　　ソースいくつか という具合に、ライブラリソースのディレクトリ直下に、ソースが有り、 なおかつ、そのライブラリの一部になっているサブディレクトリにも ライブラリのソースが有り、という状況ですが、解説ページとかを参考に、 67 名前：名無しさん＠お腹いっぱい。 [03/05/19 21:08.net] 解説ページとかを参考にして、 -- unyalibのMakefile.am ------ SUBDIRS = subDirA subDirB noinst_LIBRARIES = libunyalib.a libunyalib_a_SOURCES = unya.c honya.c -- subDirAのMakefile.am ---- noinst_LIBRARIES _ libunyalib.a libunyalib_a_SOURCES = libunyalib_a_LIBADD = unya_a.c honya_a.c -- subDirBもsubDirAと同じように"LIBADD"を使用 ---- とかいうように、書いてautomakeを動かしてみました。 でも、結果としてのMakefile.inは、どのディレクトリのものでも unyalib.a: $(unyalib_a_OBJECTS) $(unyalib_a_DEPENDENCIES) -rm -f unyalib.a $(AR) cru unyalib.a $(unyalib_a_OBJECTS) $(unyalib_a_LIBADD) $(RANLIB) unyalib.a と、ar の前に必ずrm が実行されて、一つのライブラリに合体してくれない状態です。 サブディレクトリの方ではrmの実行が挟まれず、一つのライブラリにさせる技は無いでしょうか。 68 名前：あぼーん mailto:あぼーん [あぼーん.net] あぼーん 69 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/05/19 21:50.net] そりゃサブディレクトリでやったらそれぞれ別物だし、 一つのライブラリになるわけはない罠。 70 名前：67 [03/05/19 22:48.net] えーと、やっぱ駄目ですか。 automakeって、一つの結果(実行形式でもライブラリでも)を作るためのソースは、 一つのディレクトリに集まっているというのしか想定していないということでしょうか。 71 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/05/20 20:14.net] SUBDIRS使わずに、SOURCESで相対パス指定でできなかったっけ？ $(topsrcdir)とかで指定するんだったかも。 1.4頃の記憶なんで違うかもしれん。 どっちかというとlibtoolsの話かもしれんけどね。 72 名前：67 [03/05/21 21:31.net] やってみました。 SUBDIRS無し、 libunyalib_a_SOURCES = unya.c honya.c subDirA/unya_a.c subDirA/honya_a.c とかしてみると、 subDirA下のソースに対するオブジェクトがunyalib(ライブラリソースツリーの根っこ)下に 作成されるけど、ライブラリのためのオブジェクトはサブディレクトリから取ってこようとする Makefileが出来ちゃいまひた。 で、もう、最初のMakefile.inはautomakeで作るけど、 それを手で修正して以後automakeは使わないという決定が 本日なされちゃって、この件は棚上げとあいなりました。 ありがとうございました。 73 名前：名無しさん＠お腹いっぱい。 [03/05/21 23:35.net] >>1 使いにくいのを奥深さと勘違いしてるだけだろ。 74 名前：>>53 mailto:sage [03/05/21 23:52.net] >>73 奥が深くて使いづらいと申し上げているのです。 75 名前：あぼーん mailto:あぼーん [あぼーん.net] あぼーん 76 名前：あぼーん mailto:あぼーん [あぼーん.net] あぼーん 77 名前：名無しさん＠お腹いっぱい。 [03/05/23 15:15.net] makeができない。 78 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/05/25 02:38.net] automakeで作ったMakefileってgmakeに依存する? 79 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/05/25 20:45.net] >>78 基本的には依存しない。Makefile.amの内容によっては依存する。 80 名前：あぼーん mailto:あぼーん [あぼーん.net] あぼーん 81 名前：名無しさん＠お腹いっぱい。 [03/05/30 15:01.net] >>73 バッドノウハウと「奥が深い症候群」か。 ttp://namazu.org/~satoru/misc/bad-knowhow.html こんな単純な問題じゃないと思うけどな。autotoolsがバッドノウハウの塊なのは認めるけど。でも、バッドノウハウがなくなることはないと思うよ、漏れは。 82 名前：あぼーん mailto:あぼーん [あぼーん.net] あぼーん 83 名前：あぼーん mailto:あぼーん [あぼーん.net] あぼーん 84 名前：81 mailto:sage [03/05/30 15:50.net] >>67 ん? -- unyalibのMakefile.am ------ SUBDIRS = subDirA subDirB noinst_LIBRARIES = libunyalib.a libunyalib_a_SOURCES = unya.c honya.c libunyalib_a_LIBADD = libsubdir_a.a ... -- subDirAのMakefile.am ---- noinst_LIBRARIES = libsubdir_a.a libsubdir_a_a_SOURCES = unya_a.c honya_a.c でいいんじゃないの? 手元で試してないから嘘言ってるかもしれないけど。 85 名前：81=84 mailto:sage [03/05/30 15:54.net] 間違えた。 libunyalib_a_LIBADD = libsubdir_a.a ... は libunyalib_a_LIBADD = subdirA/libsubdir_a.a ... ね。 86 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/06/05 21:26.net] auto* っつーもんは、backward compatibility を放棄した糞ということでよろしいか？ 87 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/06/06 13:26.net] Autotools で生成したものの再配布は GNU ライセンスに準じるの？ 88 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/06/06 21:30.net] >>87 準じないけど、Automakeで配布されるファイルには いろんなライセンスがあっはず。 バイナリ配るんなら問題無かったと思う。 >>86 糞かどうかは知らんが、同意したい気分だね。 89 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/06/06 22:25.net] まあ、こいつの登場で便利になっている事実は否定できないので、 backward compatibility を確保して欲しかったということだけかな。 90 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/07/14 03:42.net] backward compatibilityを維持したらどんな事態になるか分るだろ。 91 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/07/14 04:11.net] 　　 　 ∧＿∧∩　／￣￣￣￣￣￣￣￣￣￣￣ 　　　 （　´∀｀）/＜　先生！わかりません！！ 　＿ / /　　 /　　　＼＿＿＿＿＿＿＿＿＿＿＿ ＼⊂ノ￣￣￣￣＼ 　||＼　　　　　　　　＼ 　||＼||￣￣￣￣￣|| 　||　 ||￣￣￣￣￣|| 　 　 .||　 　 　 　 　 || 92 名前：あぼーん mailto:あぼーん [あぼーん.net] あぼーん 93 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/09/14 20:07.net] Automake-1.7.7のconfigureがAutoconf-2.57だと通らず、 Autoconf-2.54だと通る。 config.logは以下の通り（一部抜粋Autoconf-2.57のとき）。 configure:1724: cd conftest && eval autoconf -o /dev/null conftest.ac autom4te: no such file or directory: m4sugar/m4sugar.m4 configure:1727: $? = 1 configure:1731: error: Autoconf 2.54 or better is required. Is it installed? Is it in your PATH? (try running `autoconf --version') Is it working? See also config.log for error messages before this one. なんか情報ありませんか？ 94 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/09/14 20:53.net] お騒がせしました。ありました。 mail.gnu.org/archive/html/automake/2003-07/msg00018.html 以下のスレッドでした。でもちょっと違うんだよね。困った。 95 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/11/20 19:40.net] 犬板にあったので japan.linux.com/desktop/03/11/20/0516251.shtml 個人的にはconfigure時にはbuildなどディレクトリを掘って ../configureのほうが好み。 96 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/11/22 09:20.net] >>95 distclean できる *はず* なので、正直どうでもいい。 97 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/11/22 18:24.net] 確かにdistcleanできる *はず* ですね。 個人で開発に利用するときは、cleanすら使うことが少ないから、 良く理解していなかった。 98 名前：名無しさん＠お腹いっぱい。 [03/12/27 14:58.net] ./configureしたときのデフォルトの$prefixが/usr/localなのが不便なので、configure.ac やMakefile.acの中で--prefix=/usrの指定をできないでしょうか？ 99 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/12/27 16:19.net] >>98 AC_PREFIX_DEFAULTを使う。詳細はinfo Autoconfとかして見るべし。 しかし、デフォルトのprefixを/usrにするのはあまり行儀の良いもの ではないと思うが。 100 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/12/27 16:47.net] Makefile.ac 101 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/12/27 17:02.net] >>100 ああ、Makefile.amの間違いだよな。 102 名前：名無しさん＠お腹いっぱい。 [03/12/27 17:02.net] >>99 ありがとうございます。 ところでprefixを/usrにするとどういうデメリットがあるのでしょうか？ 103 名前：名無しさん＠お腹いっぱい。 [03/12/27 17:03.net] >>101 ごめんなさい。その通りMakefile.amの間違いです。 104 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/12/27 18:11.net] >>102 /usr の下はユーザにとって最低限必要なものが入ってるので、そういう重要なファイルと ユーザがインストールしたものの中で名前が衝突し、置き変えられたりするとまずい。 /usr/bin/cc が上書きされたらどうなるかは簡単に想像できるとおもう。 Linux とかはパッケージで入れるものは全部 /usr に入れるのが多い (衝突が検知できるから問題にならない)けど、 *BSD は別にディレクトリを掘って そこに入れてる。/usr の下は一切いじらないポリシーを厳格にまもってるんだとおもう。 105 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/12/27 19:12.net] OSの一部として配布されるもの以外は/usrに入れないのが当り前です。 システム上重要というだけでなく、そのOSを使っている人の間で構成が 一致しているからでもある。 Linuxはその意味ではいまだ寄せ集めの域を出ていないのかな? もしだとすると>>102のようになんでも/usrに叩き込むということになっちゃっ うのも納得できる。 >>104の前半にあるような問題は既にLinuxユーザでは起きているみたいだし。 106 名前：名無しさん＠お腹いっぱい。 mailto:sage [03/12/27 19:44.net] 寄せ集めっつーか、大多数のLinuxディストリにはbase systemと いう概念が無いからなぁ。「無けりゃインストールしろ」「インストール したらそれもbase systemの一部だ」みたいなノリなんだろうね。 107 名前：ヽ(´ー`)ノ mailto:sage [03/12/27 20:30.net] >>105 Linux だと FHS(File Hierarcy Standard だっけな)って標準があるよ。 最近のメジャーなディストリは準拠してる(Debian,SuSE,Fedora,Turbo...)。 特別な理由もなく --prefix=/usr するのは、お行儀の悪い鯖管だけだね。 > Linuxはその意味ではいまだ寄せ集めの域を出ていないのかな? これは、もはや昔話だよもん。 108 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/01/07 17:28.net] 一度rpmにするものは/usrにしてる。 109 名前：名無しさん＠お腹いっぱい。 [04/02/01 23:20.net] libtool.m4に入ってるチェックで、Fortranコンパイラを勝手に探したり、 maximum length of command line argumentsとか言ってCPU食うのを やめさせたいんですけど。そういうACマクロはないんでしょうか？ 110 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/02/01 23:29.net] >>109 「勝手」にチェックする m4 なんてない。 configure.{ac,in} から呼び出してる(つまり必要である)から行われてるチェック。 気に入らなきゃチェックしてるところを外せ。 # それでまともにコンパイルできるとは思えんが。 111 名前：名無しさん＠お腹いっぱい。 [04/02/01 23:36.net] えーと言い方が悪かったですが、AC_PROG_LIBTOOLマクロを使うと ほとんどのパッケージには不要なはずのチェックが盛りだくさんに はいるわけです。 とりあえず全部チェックしておけばどんな場合にも対応できるってこと なんでしょうが、不要なものをdisableにするくらいできてもいいよねえ、 そういうマクロあります？って話です。 libtool.m4が洗練されてないと言えばそれまでですがね。 112 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/02/01 23:53.net] 古いlibtool使うしかないのでは？ 113 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/02/02 19:06.net] >>109 AC_LIBTOOL_SETUPのAC_LIBTOOL_SYS_MAX_CMD_LENをコメントアウトするとか、 自分でlibtool.m4を書き換えちゃえば？ うまく動く保証は無いし、libtool使う意味も減ると思うけど。 移植性考えないんならlibtool使わなくてもいいんじゃないかな？

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef