Autoconf,Automakeについて
奥深さの前に使い方がさっぱり分からん。教えて下さい。 関連サイトは>>2 GNU Autoconf, Automake and Libtool http://sources.redhat.com/autobook/ autoconf and automake入門(チュートリアル形式) http://www.ainet.or.jp/ ~inoue/gnu/autoconf.html AUTOCONF, AUTOMAKE を使ってみよう! http://www.a2zsd.co.jp/ ~a2zsd217/book/autoconf/book1.html autoconfとは?(概要図あり) http://www.i.kyushu-u.ac.jp/ ~s-mita/autoconf.htm http://www.ainet.or.jp/ ~inoue/gnu/whatis.html > なぜ使うのか > もちろん、表の理由は、移植性の高いソフトウェアを作ることにありますが、 > 裏の理由として、GNUへの忠誠を示すことができる点があります。 ……(´д`;) configureスクリプトよく見たらsockaddr.sa_lenがあるかどうかとか チェックしてくれているのね。少し驚いたので、あげ。 >4 RMSの言う自由ってさ、ブッシュの言うそれと似てる気がする。 ま、彼も所詮「アメリカ」人ってことだーね。 ウゼえ消えろ ∧_∧ _ _ .' , .. .∧_∧ ( ´_ゝ`) _ .- ― .= ̄  ̄`:, .∴ ' ( >>1 ) / '' ̄ __――=', ・,‘ r⌒> _/ / / /\ / ̄\-―  ̄ ̄  ̄"'" . ’ | y'⌒ ⌒i _| ̄ ̄ \ / ヽ \_ | / ノ | \ ̄ ̄ ̄ ̄ ̄ ̄ \__) , ー' /´ヾ_ノ ||\ \ / , ノ ||\|| ̄ ̄ ̄ ̄ ̄ ̄ ̄|| ̄ / / / || || ̄ ̄ ̄ ̄ ̄ ̄ ̄|| / / ,' || || || / /| | !、_/ / 〉 ∧_∧ 死ね _( ´_ゝ`) / ) _ _ / ,イ 、 ノ/ ∧ ∧―= ̄ `ヽ, _ / / | ( 〈 ∵. ・( 〈__ > ゛ 、_― | ! ヽ ー=- ̄ ̄=_、 (/ , ´ノ | | `iー__=―_ ;, / / / ←>>1 !、リ -=_二__ ̄_=;, / / ,' / / / /| | / / !、_/ / 〉 / _/ |_/ ヽ、_ヽ 正 直 逝 っ て >>1 は ア ホ _,-'' ) 。゚・ 。 。 ∧ ∧ , -' (.__,-'' , , , 。゜ , - ´_ゝ`)_ .,-'~ ,- ' / / i〜i /, 。 / )ヽ(w i .,-'~ ,-'~ // , /// 〜 //, .,/ / ヽヽヽ ,-/'~ ,ノ / ////@ @// '/ / ^)'死 _ l ゝ _)-'~ ,-'~ //, ' ⌒/∨ ̄∨ ⌒ヽ / /' ヽ ^ ̄ ,-'~ / / >>1 ヽ ゚ ・ (iiiiリ∫ ヽ ./ (⌒`〜〜' /i ノ 愛 ノ\ ヽ ヽ─|〜' ノ/ ゙〜〜〜〜 | ./ `- ' || ||l、_ / ,,, | / ゚ 。 |.| _|.|_,,,| | __-'',,-~ / / .|.| ニ─、─''''| | =-''' / 、 ヽ .|.| |.| .| | | l l |.| |.| .| '、 _ _.| / ノ .|.| ,,== ==.| l .|.| ,_,,-'',,,-| / | / |.| ||_ノノ | | i、`''',,-'''' | / .| .| .|.レ `-- ' | |  ̄ | .ノ | ) ,- | | ..... | .| || `ヽ );;;::::::::''''' | | | .| ゙ - ''''''' ,- 、| | ,,,,,;;;;;;;;と__)'' \__);;;;;;;'''''' 特定のライブラリがユーザによってインストールされているかを autoconf で調べるのって邪道だと思わない? >>9 ライブラリ作者に.m4ファイルを書けってこと? そこまでFSFに魂を売り渡したくない人達はどうするよ。 たとえば、X関係とか。 なんかこの板最近殺伐としてきたな。喜ぶべきことかどうなんだろうか・・・ >11 いつのまにcross buildの機能が付いたね。FreeBSD的には有難い。 しかし、そんなこと知らずに偽cpp作ってゴリゴリhost.defとか書た 苦労はいったい・・・ autoconf、automakeのスレ、荒れてる。 もったいないよ、盛り上げようよ。 何もわかってない馬鹿が暴れてるんだろうな >>8 >>12 configure.inを書かずにGPLで配布することは恥かしいことなんですか?(w >>18 configure.in configure.acを利用しない方が恥ずかしい罠。 >>10 autoconf は OS 間の非互換性を補う使い方に留めてほしい。 自分がリンクしたいライブラリが無かった時、勝手に WITHOUT_LIBHOGE みたいなオプションを付けてそれ抜きでコンパイルするのは嬉しくない。 そのライブラリを使うか使わないかはユーザが決める事柄なんだから、 --with-libhoge とも --withoug-libhoge とも指定してないのに、勝手に WITHOUT_HOGE とかして欲しくない。 黙ってコンパイルして、黙ってリンカエラーを出してくれればそれでいい。 事前に親切に「libhoge ねえぞ、入れろやゴルァ」と言ってくれれば便利だが、 そこまでは求めない。 あと、OS 標準じゃない物を探すんだったら /usr/lib と /usr/include 以外の場所も適宜探してくれないと不便だと思う。何でも /usr 直下に 突っ込むことを暗黙の前提としているのではないか。 了解。勘違いしていた。 >>21 > 自分がリンクしたいライブラリが無かった時、勝手に WITHOUT_LIBHOGE > みたいなオプションを付けてそれ抜きでコンパイルするのは嬉しくない。 これは同感です。 # というより、Autoconfの使い方が悪い。 > 黙ってコンパイルして、黙ってリンカエラーを出してくれればそれでいい。 これやっちゃうと、バグの報告が大量に発生すると思うので、マトモなパッ ケージなら、 > 事前に親切に「libhoge ねえぞ、入れろやゴルァ」 と言ってくれると思うんですがどうでしょう。 # マトモの定義の話は無しね。 多分、Makefileを適切に書くのが面倒だから「Automake Autoconfでパッケー ジ作りました」ってのが多いんだと思う。AC_CHECK_XXXの引数できちんとエラー 処理すれば大丈夫でしょ。 > あと、OS 標準じゃない物を探すんだったら /usr/lib と /usr/include > 以外の場所も適宜探してくれないと不便だと思う。 ライブラリについてはリンクを実際に行なって調査するので、ユーザが環境変 数を設定することで何とかなりますし、ヘッダの方もコンパイル可能かどうか を調査するので同じことではないでしょうか? ま、言いたいのは、道具はいいけど使い方は人それぞれってことです。 関係ないんだけど、いいですか? UNIXの人はWindowsでプログラミングするときは nmakeとcygwin(gmake)のどっち使ってますか? nmake使いづらいです。。 >>24 nmakeってことはVC++? だったらmsdev使うけど。 >26 バカヤロウ。ここはUNIX板。 Windowsはcygwinを入れて使うもんだろ。 コンパイラまでgnuを使うわけにはいかないことも あるが、それ以外は当然全てgnu! Automake 1.6.2 released sageですが ;-) 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は出来ないし。 >>29 > JavaプログラムをAutoconf/Automakeに対応させるにはどうしたらいいのかな? > 最低限 make と make install と make dist を使えるようにしたいのだけど。 Automake-1.6.2とAutoconf-2.53だと、gcjを利用したコンパイルができるみたい。 でも、うちはJAVAの環境が無いから試せないです。 automakeのinfoの、ノード"Java Support"を参照してみてください。 >>30 gcjを入れてみたけどlibgcj.specが????とか出て動かない。かなり険しそう(w とりあえずAutomake-1.4のinfoで'_JAVA'がどうのこうのって記述を見つけたので、 javacで動くように試してみます。 >>31 > とりあえずAutomake-1.4のinfoで'_JAVA'がどうのこうのって記述を見つけたので、 > javacで動くように試してみます。 1.4のやつって、javacでのコンパイルのみのサポートだったと思います。 # 記憶が曖昧ですみません。 info にもありますけど、.javaと.classのサフィックスルールを自動的に作れ ない(ファイルの中からクラス名を調査する必要がある)のでそのような仕様だっ たと思います。だからmakeはできてもmake installは難しいと思います。 # でもうまくいったら教えてください。 Autoconf-2.53b 開発版リリース(結構前だけど) どーでもいいけど、autoconf-mode.elとかautotest-mode.elとかあるのね。 色が変わるだけみたいだけど。 知らない間にac-2.54 am-1.7になってたのね。 amのdrilistって便利そうなんだけど使っている人いる? --confiugre=$HOMEしている人ぐらいなのかな。 # ム板のmmmpスレのほうが活発かな? autoconfは便利なんだけど、これに対応するようになってから ソースの見通しが悪くなった。 前は環境依存部分を別関数にしたりしてたけど、最近は面倒だからやめた。 確かに見通しは悪くなった。GNUのソースも見るのが辛くなってきた。 # なんか愚痴ばっかりだな。 この前からCommon Lispで書かれた数式処理ソフトウェアの構成を 追ってみようとしてるんだけど、main関数のないLispソースを autotoolsでビルドする構成になってるので、さっぱり分からない。 Autotoolsを使うときには、想定しているコンパイラ・ライブラリの組み合わせと 依存関係を簡単にドキュメント化してくれないと困ってしまう。 逆に移植などがし辛くなってしまうよ。 >>40 とりあえずconfigureしてlog見るんじゃだめなの? Common Lisp知らないからいい加減なこといっているけど。 コンパイル型言語じゃないからね、Lispの「メモリダンプ」とかって独特なんです。 で、どんなコマンドが実行されてるんだか (というか、山ほど実行されてるコマンドのうちどれが重要なのか)分からない。 いろいろ大変なんですね。LispはEmacsのしか知らないし、 AM_PATH_LISPDIR使っているものしか見たこと無いんで、 役に立たずですまんです。 # autoconfにもLispファイルがあります。 Autoconf,Automake,Libtoolを解説してる本って少ないながらも一応あるようですけど, どんなもんでしょう?いい本なのでしょうか? 多分あの本だと思いますがいい本です。ただし、最新のAutoconf、Automakeを 利用するとちょっと戸惑うかもしれません。セレンディップのGNOMEプログラ ミングという本にもこれらの解説があります。 >>46 そうだと思う。 んでも、少々高いから、漏れは立ち読みで逝こうかとw CVSにconfigureまで突っ込んでるプロジェクトもたまに ありますが、ふつうはどこまで含めるものなんですか。 FreeBSD PORTS なんかだと、 autoconf{,213,254,257} や automake{,14,16,17} や libtool{,13,14} のように、 古いバージョンも後生大事に用意されていますよね。 これは何故なんでしょうか? 何か後方互換性に大きな問題でもあるのでしょうか? >>55 なるほど。 そうだとして、この場合はそれぞれこのバージョンを使えば良い/いけない、 といった判断は一般にどのような基準に基づいて行えば良いのでしょうか? >56 違うバージョンを使うと動かないので悩む必要はありません。 >>57 う〜ん、やっぱり良くわからないです。 とどのつまり、知りたいのは、 PORTS や package のような仕組みの無い OS に automake や autoconf を入れる場合、 とりあえずそれぞれ最新のバージョンのを入れておけば問題ないものなんでしょうか? それとも、古いバージョンのも入れておいた方が良いのでしょうか? >>53 configure.acまでと言いたいが、今のAutotoolsのバージョン間の互換性から、 configureまで入れておいたほうが無難。誰でもcheckoutできるプロジェクト なら、「autoconfを実行するとエラーが出ます」というレポートが大量発生す る可能性が高い。しかし、confugure.acやMakefile.amを書き換えると同じ状 況になるんだよね。 AM_INIT_AUTOMAKE([1.7])とかAC_PREREQ(2.57)とか書けばいいのかな? >>58 Autotoolsを自分のプロジェクトで使うのなら、最新を入れて問題ないです。 他のプロジェクトに参加するなら、そのプロジェクトが推奨するバージョンが あります。適当にソース持ってきて自分でソースなどを修正する時は、そのソー スを書いた人が使っているものと同じバージョンがないとうまく動かないこと もあります。更に、これらのツールは同じprefixにインストールしないとうま く動かない場合が多いです。 私は、$HOME以下のディレクトリにいろんなバージョンが入っているのですが、 libtoolだけはいい方法が見つからないです。 >>59 さんくす。内輪のプロジェクトなんでconfigure.acまでにしときます。 すでにautotoolsの互換性に悩んでるんだけど、最新版推奨で行くことにします。 configureはtarballに入れればいいし。 >>60 どうもです。 私はとくに他人のプロジェクトに参加したりということもなさそうですので、 最新のを入れて問題なさそうですね。 とあるソフトの configure.in、 AC_SEARCH_LIBS(tputs, ncurses termcap, HAVE_TERMCAPとdefine, ダメです) みたいなライブラリチェックしかなくてSolaris8上でのconfigureが不能です。 対症療法よりもその辺全面的に書き換えようと思うんで、 configure.in での termcap, curses, ncursesのチェックのお手本になるソフト探してます。 readlineをリンクすることも可能で、Solarisでconfigure;make 可能なソフト、 なんかないでしょうか?gdb? >>63 GNU texinfoが、tercap、ncurses、readlineなどを使ってるみたいです。 infoコマンドのソースはgdbより少ないかな? >>64 情報ありがとうございます。当たってみます。 済みません、ちょとお邪魔させてください。 事情により初めてautoconf/automake使い始めたとこなんですが、 unyalib--------------------subDirA ソ ースいくつか | ソースいくつか | | |-----subDirB ソースいくつか という具合に、ライブラリソースのディレクトリ直下に、ソースが有り、 なおかつ、そのライブラリの一部になっているサブディレクトリにも ライブラリのソースが有り、という状況ですが、解説ページとかを参考に、 解説ページとかを参考にして、 -- 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の実行が挟まれず、一つのライブラリにさせる技は無いでしょうか。 そりゃサブディレクトリでやったらそれぞれ別物だし、 一つのライブラリになるわけはない罠。 えーと、やっぱ駄目ですか。 automakeって、一つの結果(実行形式でもライブラリでも)を作るためのソースは、 一つのディレクトリに集まっているというのしか想定していないということでしょうか。 SUBDIRS使わずに、SOURCESで相対パス指定でできなかったっけ? $(topsrcdir)とかで指定するんだったかも。 1.4頃の記憶なんで違うかもしれん。 どっちかというとlibtoolsの話かもしれんけどね。 やってみました。 SUBDIRS無し、 libunyalib_a_SOURCES = unya.c honya.c subDirA/unya_a.c subDirA/honya_a.c とかしてみると、 subDirA下のソースに対するオブジェクトがunyalib(ライブラリソースツリーの根っこ)下に 作成されるけど、ライブラリのためのオブジェクトはサブディレクトリから取ってこようとする Makefileが出来ちゃいまひた。 で、もう、最初のMakefile.inはautomakeで作るけど、 それを手で修正して以後automakeは使わないという決定が 本日なされちゃって、この件は棚上げとあいなりました。 ありがとうございました。 >>1 使いにくいのを奥深さと勘違いしてるだけだろ。 >>73 奥が深くて使いづらいと申し上げているのです。 automakeで作ったMakefileってgmakeに依存する? >>78 基本的には依存しない。Makefile.amの内容によっては依存する。 >>73 バッドノウハウと「奥が深い症候群」か。 ttp://namazu.org/~satoru/misc/bad-knowhow.html こんな単純な問題じゃないと思うけどな。autotoolsがバッドノウハウの塊なのは認めるけど。でも、バッドノウハウがなくなることはないと思うよ、漏れは。 >>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 でいいんじゃないの? 手元で試してないから嘘言ってるかもしれないけど。 間違えた。 libunyalib_a_LIBADD = libsubdir_a.a ... は libunyalib_a_LIBADD = subdirA/libsubdir_a.a ... ね。 auto* っつーもんは、backward compatibility を放棄した糞ということでよろしいか? Autotools で生成したものの再配布は GNU ライセンスに準じるの? >>87 準じないけど、Automakeで配布されるファイルには いろんなライセンスがあっはず。 バイナリ配るんなら問題無かったと思う。 >>86 糞かどうかは知らんが、同意したい気分だね。 まあ、こいつの登場で便利になっている事実は否定できないので、 backward compatibility を確保して欲しかったということだけかな。 backward compatibilityを維持したらどんな事態になるか分るだろ。 ∧_∧∩ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ( ´∀`)/< 先生!わかりません!! _ / / / \___________ \⊂ノ ̄ ̄ ̄ ̄\ ||\ \ ||\|| ̄ ̄ ̄ ̄ ̄|| || || ̄ ̄ ̄ ̄ ̄|| .|| || 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. なんか情報ありませんか? 犬板にあったので http://japan.linux.com/desktop/03/11/20/0516251.shtml 個人的にはconfigure時にはbuildなどディレクトリを掘って ../configureのほうが好み。 >>95 distclean できる *はず* なので、正直どうでもいい。 確かにdistcleanできる *はず* ですね。 個人で開発に利用するときは、cleanすら使うことが少ないから、 良く理解していなかった。 ./configureしたときのデフォルトの$prefixが/usr/localなのが不便なので、configure.ac やMakefile.acの中で--prefix=/usrの指定をできないでしょうか? >>98 AC_PREFIX_DEFAULTを使う。詳細はinfo Autoconfとかして見るべし。 しかし、デフォルトのprefixを/usrにするのはあまり行儀の良いもの ではないと思うが。 read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる