Autoconf/Automake/Libtool

1 名前：デフォルトの名無しさん [2006/05/23(火) 23:14:55 ] 使いこなしてｶｯｸｲｲ！ 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