Autoconf/Automake/Libtool

1 名前：デフォルトの名無しさん [2006/05/23(火) 23:14:55 ] 使いこなしてｶｯｸｲｲ！ 6 名前：デフォルトの名無しさん mailto:sage [2006/05/26(金) 23:23:12 ] 設定ファイルの為のツールというのが解せない 素直にMakeあたりの機能を拡張した方がよくね？ UNIXの精神とやらにそぐわないのかな 7 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 01:06:19 ] いや、autoconfを使い倒すことこそGNUへの忠誠心の表れだろう。 と、マニュアルには書いてある。 8 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 01:39:17 ] >>6 WebブラウザとHTMLエディタを一緒にするようなもんか 9 名前：デフォルトの名無しさん [2006/05/27(土) 02:51:54 ] 今どきのマーはレガシーなautotoolなんて知らないんじゃないの？ 10 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 10:45:28 ] >>6 違うだろ makeファイル自動生成ツールだろ 11 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 17:00:01 ] こいつらキライ 高々ビルドにこんな労力が必要なのは間違ってる 12 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 17:18:12 ] じゃあ使わなければいい 13 名前：デフォルトの名無しさん [2006/05/27(土) 19:40:26 ] >>11 autoconfが悪いんじゃない。 悪いのはUNIX環境の統一の無さ。 14 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 22:11:46 ] まあその分、autotoolsが動けばどんな環境でもMakefileが通るようにはできるけどね。 もちろん、実際にプログラムが動くかどうかは別の話だけど。 15 名前：デフォルトの名無しさん mailto:sage [2006/06/06(火) 23:39:22 ] 4000円は高い もっと安い本は無いものか 16 名前：デフォルトの名無しさん mailto:sage [2006/06/07(水) 08:11:29 ] 英語だと最新版だし、タダだよ 17 名前：デフォルトの名無しさん mailto:sage [2006/08/13(日) 21:29:23 ] autoconfを使えるようにしようと下のサイト ttp://www.ogis-ri.co.jp/otc/hiroba/technical/CppUnit/chapter3.html のサンプルを試しています。 automakeがinstall-shをconfig以下に作るのはいいのですけどconfigure の方のac_aux_dirが空のままで./configureを実行すると configure: error: cannot find install-sh or install.sh in . ./.. ./../.. となってMakefileが作られません。 aclocal --acdir=configも試したのですが aclocal: configure.ac: 6: macro `AM_INIT_AUTOMAKE' not found in library となってしまいます。今使っているのはautoconf 2.5xなのでサンプル 通りにはいかないのでしょうか？ configureでac_aux_dir=configと手動で設定してやれば./configureは 成功するのですが自動生成する方法はないでしょうか？ 18 名前：デフォルトの名無しさん mailto:sage [2006/08/13(日) 22:50:56 ] >>17 とりあえず $ autoreconf -vfi とかしてみたり、 $ autoupdate などで、autoconf-2.5xに対応してみては？ 19 名前：デフォルトの名無しさん mailto:sage [2006/08/14(月) 00:54:53 ] >>18 やってみましたが効果なしです。 20 名前：デフォルトの名無しさん mailto:sage [2006/08/14(月) 00:58:23 ] >>17 >今使っているのはautoconf 2.5xなのでサンプル通りにはいかないのでしょうか？ 2.59でうまくいくよ dicegame-0.1.tar.gz展開してbootstrap実行してできたconfigureのac_aux_dirは うちでは以下のようになってる ac_aux_dir= for ac_dir in config $srcdir/config; do if test -f $ac_dir/install-sh; then ac_aux_dir=$ac_dir ac_install_sh="$ac_aux_dir/install-sh -c" break elif test -f $ac_dir/install.sh; then ac_aux_dir=$ac_dir ac_install_sh="$ac_aux_dir/install.sh -c" break elif test -f $ac_dir/shtool; then ac_aux_dir=$ac_dir ac_install_sh="$ac_aux_dir/shtool install -c" break fi done 21 名前：デフォルトの名無しさん mailto:sage [2006/08/14(月) 08:47:23 ] >>20 どうやらconfigure.ac(configure.in)でAM_INIT_AUTOMAKE の後にAC_CONFIG_AUX_DIRを書いていたのがいけなかったみ たいです。 下のサイトにautoconf2.5xでは 「AC_INAC_INITの直後にAM_INIT_AUTOMAKE書く。」 と書いてあったので、それを実践していました。 www.saiin.net/~silphire/tips/autoconf.html 22 名前：デフォルトの名無しさん mailto:sage [2006/08/15(火) 14:09:10 ] CppUnit::TestFactoryRegistry::getRegistry().makeTest() を使うとテストが二回り行われてしまします。 それを防ぎたいのですけど何か設定とかあるのですか？ 23 名前：デフォルトの名無しさん [2006/10/31(火) 01:42:58 ] いま再び読み始めたのでageとこ GNU Make の後に読んでるからかやっと意味がわかった 前読んだときは書いてあることがまったくわからんかったのに・・・ 「./configure;make;make install;」って今までおまじないでしかなかったのに・・・ みんなすごいね、中の人が何やってるか理解してつかってるの？ 24 名前：デフォルトの名無しさん mailto:sage [2006/10/31(火) 03:02:37 ] まぁ、そこら辺はどのアプリでも殆ど同じだからね。 25 名前：デフォルトの名無しさん [2006/11/01(水) 01:34:59 ] 良スレ上げ 26 名前：23 [2006/11/06(月) 17:24:27 ] mkinstalldirsの処理の中の後半部分で exec mkdir をした後の処理 for file do set fnord `echo ":$file" | sed -ne 's/^:￥//#/;s/^://;s/￥// /g;s/^#/￥//;p'` ・・・ ここのforループは何をしてるのでしょうか？ exec mkdir したところで mkinstalldirs の処理が終わってる気がするのですが？ #! /bin/sh -xv と デバッグ用echo, デバッグ用touch で追いかけてみても exec mkdir 以降の処理はやってない気がするのですが？？ なにか勘違いしているのだろうか？？？ 27 名前：デフォルトの名無しさん mailto:sage [2006/11/06(月) 21:16:27 ] >>26 バージョンが古いのでは？ automake-1.9以降はそうなっていない。 28 名前：23 [2006/11/06(月) 22:13:26 ] おお、さんくす 確認してみたら automake-1.6 だった。MacOSX 10.4.8 そうか、古いのか・・・ 29 名前：23 [2006/11/07(火) 12:32:13 ] automakeはPerlスクリプトなのね。autoconfはshスクリプトだし このあたりのスクリプトの集合体なわけですか、なるほど 30 名前：23 [2006/11/16(木) 14:03:14 ] 単体テストの骨組みもあるんだね、単純に配布ツールだと思ってた 31 名前：デフォルトの名無しさん mailto:sage [2006/11/16(木) 21:27:33 ] >>30 autotest関係はいまだ不安定かも。(2.60では大丈夫なのかな？) というか、テスト全部にconfigure.ac書くのはめんどくさいかも。 不安定っていうのは、仕様変更が今後もありうるかもって意味であって、 動作が不安定ってわけじゃないので、安心してください。 32 名前：デフォルトの名無しさん [2006/11/17(金) 01:04:41 ] あるプログラムのmake中に以下のようなメッセージが出たのですが、どうたいしょすればいいのでしょうか？ autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal  --output=aclocal.m4t aclocal: macro `AM_PATH_PYTHON' required but not defined aclocal: configure.ac: 22: macro `AM_GLIB_GNU_GETTEXT' not found in library autoreconf: aclocal failed with exit status: 1 AM_PATH_PYTHONとかAM_GLIB_GNU_GETTEXTは、何に何を設定すればいいのでしょうか？ 33 名前：デフォルトの名無しさん mailto:sage [2006/11/17(金) 07:51:28 ] >>32 > AM_PATH_PYTHONとかAM_GLIB_GNU_GETTEXTは、何に何を設定すればいいのでしょうか？ これらのマクロがインストールされていないため。 うちでは、 /usr/share/aclocal-1.10/python.m4　(automake-1.10) /usr/share/aclocal/glib-gettext.m4　(glib-2.12.4) にインストールされてる。 34 名前：デフォルトの名無しさん [2006/11/17(金) 23:50:25 ] >>33 ありがとうございました。 助かりました。 35 名前：23 [2006/11/18(土) 21:03:37 ] メモ： configure.in のひな形 configure.scan は autoscan で作れる。 autoscan はPerlのスクリプトである。 どのような基準でひな形を生成しているかは Perlスクリプトを読まなければならない、多分 Perl わかんねからそっちの勉強しよ 36 名前：デフォルトの名無しさん mailto:sage [2006/11/19(日) 09:34:20 ] >>35 > どのような基準でひな形を生成しているかは Perlスクリプトを読まなければならない、多分 info 読んだ方が楽だと思うけど、、、 後は、適当なソース書いて、autoscanしてconfigure.scanを見るとか。 37 名前：23 [2006/11/19(日) 10:50:00 ] おお、さんくす ＞info 読んだ方が楽だと思うけど、、、 確かに info autoscan 見たら詳しく書いてあった。 man autoscan だけしか見てなかったから動作基準が解らなかった。 # man の SEE ALSO 項目なんて全然意識してなかった いままで ＞後は、適当なソース書いて、autoscanしてconfigure.scanを見るとか。 コレしてたんだけど in/out の動作原理が解らなかった. ありがとう 38 名前：23 [2006/11/21(火) 22:44:16 ] めも： Autoconf/Automake/Libtool　この本は今イチよく解らない。でも代わりの良い本は解らない ググったかんじでは Automakeでmakeする ttp://www.02.246.ne.jp/~torutk/cxx/automake/automake.html ここが解りやすかった。あと マニュアルの日本語訳 ttp://www.geocities.jp/fut_nis/ 39 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 17:33:58 ] Autotools の使い方について質問させてください。 フォルダ配置がこのようにようになっていて main   ･ configure.ac   ･ Makefile.am   --src folder       ･ Makefile.am       ･ xxx.c   --include folder configure.ac, Makefile.am それぞれに 次レスのような内容を記述しています。 make をした後コンパイルには成功するのですが なぜかオブジェクトファイルがどこにも見つからずライブラリが作れない状態です (´･ω･`)ｼｮﾎﾞｰﾝ コンパイルエラーは表示されないのでコンパイルには成功してると思うのですが･･･ どなたか対処法分かる方いませんか？ 40 名前：続き mailto:sage [2006/12/29(金) 17:34:30 ] ------- configure.in -------- AC_INIT(xxx) AM_INIT_AUTOMAKE([foreign]) AC_CONFIG_SRCDIR([src/xxx.c]) AC_CONFIG_HEADER([config.h]) AC_PROG_CC AC_PROG_RANLIB AC_PROG_INSTALL AC_CONFIG_FILES([Makefile                  src/Makefile]) AC_OUTPUT ------- Makefile.in -------- SUBDIRS = src ------- src/Makefile.in -------- INCLUDES = -I. -I.. -I../include noinst_LIBRARIES = libxxx.a libxxx_a_SOURCES = xxx.c 41 名前：デフォルトの名無しさん [2006/12/30(土) 02:32:27 ] age 42 名前：デフォルトの名無しさん mailto:sage [2006/12/30(土) 10:04:53 ] >>39 > なぜかオブジェクトファイルがどこにも見つからずライブラリが作れない状態です (´･ω･`)ｼｮﾎﾞｰﾝ .libs 以下にできてるとか、、、というか、libtoolを使えば？ 43 名前：デフォルトの名無しさん mailto:sage [2006/12/30(土) 14:00:36 ] >>40 一応確認するが、このコピペはconfigure.acとMakefile.amだよな? configure.inとMakefile.inじゃなくて。 前者はともかく、後者は違っているとダメだと思うぞ。 で、それはそれとして。 make clean all >& make.log とでもしてログを吐き、 ログの中のコンパイルしている箇所を観察すれば、 どこにオブジェクトファイルを出力したのか(あるいはコンパイル自体していないのか) わかるはず。 44 名前：デフォルトの名無しさん mailto:sage [2006/12/30(土) 16:36:14 ] >>42 .libs を探してみたのですが、ありませんでした。 autotoolsは今でもいっぱいいっぱいなので、 libtool はとりあえず後回しで・・・orz >>43 失礼しました。Makefile.amです。 ﾛｸﾞも見てみたのですが、何が原因か全く分かりませんヽ(`Д´)ﾉｳﾜｧｧｧﾝ このままだと埒が明かないので、 自分がコンパイルしようとしたサンプルプログラムをアップします。 wonder.bms.ms/tower/bin/sugoiuploader/img/037.zip （>>39-40から内容を少し変えてあります） make.log や Makefile も残しておいたので、 原因が分かる方がいたらほんとに教えてください。(人∀･)ﾀﾉﾑ また、理由はよく分からないのですが gcc コマンドを手打ちして オブジェクトファイルを作れば、メイクには成功します。 自分の実行したコマンドは build にあります。 45 名前：デフォルトの名無しさん mailto:sage [2006/12/30(土) 18:40:59 ] >>44 取れないので。取れた人よろしく。 46 名前：44 mailto:sage [2006/12/31(日) 01:55:48 ] すいません。あぷろだの調子が悪いかもしれません。 別の所にアップし直しました。 gamdev.org/up/img/8499.zip 47 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 02:42:31 ] >>46 src/Makefile.amの内容が40の（src/Makefile.in）とずいぶん違うようだが... とりあえず実行権限が付与されてあるべきファイルで実際には付与されていないのがいくつかある xxx/configure xxx/depcomp xxx/depcompを消してautomakeで作りなおしたらうまくいったよ 48 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 08:46:51 ] >>46 autoconfのバージョンが違うので、うちではAC_INIT([xxx],[0.0.0])にしないとNG。 というか、AC_INIT か AM_INIT_AUTOMAKEのどちらかで PACKAGEとVERSIONを指定しないと不味いはず。 # make dist なんてやると分かる。 src/Makefile.amで noinst_LIBRARIES = libxxx.a libxxx_a_SOURCES = xxx.c をやりたければ、configure.acに AC_PROG_RANLIB を付けないと怒られた。 まあ、47が書いている実行権限の問題以外はゴミみたいな話だが。 ちなみに、 automake (GNU automake) 1.10 autoconf (GNU Autoconf) 2.61 な環境。 49 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 14:46:53 ] ﾟ･*:.｡..｡.:*･゜ヽ( ´∀`)人(´∀` )ノ･゜ﾟ･*:.｡..｡.:* >>47 出来ました！ 実行権限の問題だったのですね ありがとうございます。 >>46 バージョンの方も指定するようにしました。 いろいろとありがとうございます。 ﾟ･*:.｡..｡.:*･゜ヽ( ´∀`)人(´∀` )ノ･゜ﾟ･*:.｡..｡.:* 50 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 14:47:52 ] ↑ >>46ではなく>>48です^^ 51 名前：デフォルトの名無しさん [2007/01/13(土) 16:34:59 ] Makefile.amを使ってMakefileを作っています。 ソースがincludeしているヘッダファイルが修正されたときに、そのソースを自動で コンパイルし直す様なMakefileを作るにはどうすれば良いでしょうか？ 52 名前：デフォルトの名無しさん mailto:sage [2007/01/13(土) 16:50:38 ] >>51 普通にそのようなMakefileができますが... 53 名前：デフォルトの名無しさん [2007/01/13(土) 16:56:12 ] すみません。 自動でやってくれていました。 54 名前：デフォルトの名無しさん [2007/01/13(土) 16:57:51 ] 依存してないファイルを修正して試してました。 依存している物で試したら上手く処理してくれましたorz。 55 名前：デフォルトの名無しさん mailto:sage [2007/04/02(月) 07:17:53 ] 質問です。 autotoolsを使ってプログラムを作ろうとしています。 プログラム、main を作ろうとし、 mainはobjA.Oをリンクさせる必要があります。 さらに、objA.oはobjB.oをリンクさせる必要があります。 #このようなイメージです main -依存-> objA.o -依存-> objB.o このような場合、Makefile.amには bin_PROGRAMS=objB objA main # objA.oの.oを付けるとエラーが出てしまったのでつけてません # objBを生成するための objB_SOURCES=sourceb.cpp # objAを生成するための objA_SOURCES=sourcea.cpp objA_LDADD=objB # mainを生成するための main_SOURCES=main.cpp objA_LDADD=objA このように書かなくてはならないのでしょうか？ 56 名前：デフォルトの名無しさん mailto:sage [2007/04/02(月) 10:30:33 ] >>55 根本的に、autoconf、libtoolは移植性 automakeはパッケージ作成のためなので、 外部のオブジェクトとリンクするパッケージでは、 autotoolsを使うメリットは無いでしょう。 そういうわけでは無く、autotoolsの勉強なら、 パッケージ構成を見直した方が良いと思います。 57 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 12:32:21 ] >>56 了解しました。ちょっと見直してみます。 さらに質問で悪いのですが、 prog_SOURCES=a.c b.c c.c とした場合、 a.c, b.c, c.cそれぞれのコンパイルに対してオプションを付けたい場合は どのようにMakefile.amに書けばよいのでしょうか？ 58 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 02:39:15 ] >57 >a.c, b.c, c.cそれぞれのコンパイルに対してオプションを付けたい場合は それぞれ別々のオプションをつけたいってこと？ info の Per-Object Flags Emulation を参照。 59 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 11:08:22 ] >>58 ありがとうございます 60 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 18:28:09 ] automakeに詰まってばっかりです・・・ また質問なのですが ./src 　source1.cpp 　./subsrc 　　source2.cpp という構成で、./srcにlibtest.aを作りたい。という状況です。 この場合、./src/Makefile.amに libtest_a_SOURCES=source1.cpp subsrc/source2.cpp と書くしか方法は無いのでしょうか？ ./src/Makefile.amには./srcにあるファイルを、./src/subsrc/Makefile.amには./src/subsrcにある ファイルを記述した方が管理が楽だろうと考えているのですが・・・ 61 名前：デフォルトの名無しさん mailto:sage [2007/04/14(土) 16:23:55 ] >60 本当にやりたいことは何なのか整理した方がいいと思う。 src 以下のソースを全部まとめて libtest.a を作りたいんだよね？ libtest.a に対する指定で subsrc に対して言及しなければいけないのは当然。 subsrc 以下のソース「全て」を記述するのが面倒だ、という意味で、libtool を使うのも辞さないというなら # src/subsrc/Makefile.am noinst_LTLIBRARIES=libsubsrc.la libsubsrc_la_SOURCES=source2.cpp # とか色々 # src/Makefile.am lib_LIBRARIES=libtest.a libtest_a_SOURCES=source1.cpp libtest_a_LIBADD=subsrc/libsubsrc.la で、いけるんじゃない？ 62 名前：デフォルトの名無しさん [2007/06/24(日) 22:46:03 ] makefileって自分で書くんじゃなくてautoconf/automakeで作るものなの？ 開発途中は自分でmakefile作って、ある程度完成したらその段階で./configure でmakefile を作ってもらうほうがいいの？ 63 名前：デフォルトの名無しさん mailto:sage [2007/06/24(日) 22:58:31 ] >>62 自分で書いた方が多分楽です。 配布のときに make dist できる程度かな？ 64 名前：デフォルトの名無しさん mailto:sage [2007/06/25(月) 02:27:47 ] make distも自分で書けばいい 65 名前：デフォルトの名無しさん mailto:sage [2007/06/27(水) 01:48:27 ] >62 複数の環境でビルドすることを考えるなら Autotools を使う方が楽だろう。 恐らく、そんな質問をしている時点では自前で Makefile を書いた方が楽だ。 66 名前：デフォルトの名無しさん [2007/09/17(月) 20:14:26 ] foo-1.0/src/a.c foo-1.0/test/b.c があって、a.c は -O2 で、b.c は -O0 でコンパイルしたいと思っています。 test/Makefile.amに、 bin_PROGRAMS=b b_CFLAGS=-O0 と書いてみたのですが、 gcc -O0 -O2 (中略) b.c のようにコンパイルされてしまい(上から渡ってくる?CFLAGSの-O2がb_CFLAGSより後ろにきて しまって)最適化がかかってしまいます。test/Makefile.amに CFLAGS= という行を追加すればいいかともおもったんですが、これもautomakeに `CFLAGS' is a user variable, you should not override it; などとと怒られてしまいます。 test/Makefile.amにAM_CFLAGS=-O0 を書き足しても、b_CFLAGSと同じ効果しか得られません。 どうしたらよいか教えていただけませんか？ 67 名前：デフォルトの名無しさん mailto:sage [2007/09/18(火) 01:16:57 ] >>66 CFLAGSなどはユーザ(パッケージを使う人)が制御するものなので、 パッケージメンテナが強制してはならない。 Makefile.amはパッケージメンテナが書くものなので、 その中で最適化オプションを強制するのは厳禁。 これを体現するため、ユーザ指定のCFLAGSは必ず最後に付加されることになってる。 詳しくは automake.info の FAQ の "Flag Variables Ordering" でも読んで。 回避するハックがあるかどうかは知らないが、お勧めしない。 ユーザとしてその場で行いたいだけなら、次のようにすればOK。 cd test; make CFLAGS=-O0 b.o 68 名前：デフォルトの名無しさん mailto:sage [2007/09/18(火) 01:25:02 ] 了解です。 69 名前：デフォルトの名無しさん [2007/12/31(月) 17:07:13 ] wxWidgetsをリンクするために 'wx-config --cppflags'の出力されたものを 作成ファイルのMakefile.am内オプションに追加したいのですが いったいどうやればいいのですか？ ついでに、何度か同じことをする必要があるので 共通の変数か何かに設定できるとうれしいです。 70 名前：デフォルトの名無しさん [2008/01/26(土) 23:26:58 ] automakeでcのソースをc++コンパイラでコンパイルするように指定することってできるのでしょうか？ 71 名前：デフォルトの名無しさん mailto:sage [2008/03/09(日) 17:46:07 ] HOS 72 名前：デフォルトの名無しさん mailto:sage [2008/03/09(日) 17:51:09 ] Hyper Operating System for labors 73 名前：デフォルトの名無しさん [2008/06/12(木) 00:21:03 ] Linuxでアプリ配布するなら、やっぱりAutoconf使うべきなのかな？ それとも、メジャーなディストリでビルドできればいいよくらいのスタンスなら、 自前MakefileでもOK？　みなさんどうお考えですか? 74 名前：デフォルトの名無しさん mailto:sage [2008/06/12(木) 01:14:19 ] auto-tools は Unix 系 OS の差分を吸収するために存在するものなので, Linux だけが対象だと auto-tools である必要はないと思われる。 「auto-tools は GNU 教への帰依の度合いを計る試金石として存在している」 と言う話を, どこかで効いたような気がするw 75 名前：デフォルトの名無しさん mailto:sage [2008/06/12(木) 02:38:37 ] >>73 とりあえず配布してみれ．それが役に立つアプリで他のOS環境でも 動かしたいと思う人がいればきっとその人がautotoolizeしてくれるよ． 76 名前：デフォルトの名無しさん mailto:sage [2008/06/12(木) 13:39:40 ] ビルドスクリプトとしてだけならともかく、いくつもの環境に対応しようと #ifdefとかが絡んでくるようになると autotoolsが枠組みを最初から用意してくれているのはそれなりに便利。 77 名前：デフォルトの名無しさん mailto:sage [2008/06/12(木) 14:20:12 ] 公開するんなら、README.1STに「誰かautotools対応して〜X-<」とでも入れておくとか？

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

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