06/12/31 14:47:52
↑ >>46ではなく>>48です^^
51:デフォルトの名無しさん
07/01/13 16:34:59
Makefile.amを使ってMakefileを作っています。
ソースがincludeしているヘッダファイルが修正されたときに、そのソースを自動で
コンパイルし直す様なMakefileを作るにはどうすれば良いでしょうか？
52:デフォルトの名無しさん
07/01/13 16:50:38
>>51
普通にそのようなMakefileができますが...
53:デフォルトの名無しさん
07/01/13 16:56:12
すみません。
自動でやってくれていました。
54:デフォルトの名無しさん
07/01/13 16:57:51
依存してないファイルを修正して試してました。
依存している物で試したら上手く処理してくれましたorz。
55:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/04/02 10:30:33
>>55
根本的に、autoconf、libtoolは移植性
automakeはパッケージ作成のためなので、
外部のオブジェクトとリンクするパッケージでは、
autotoolsを使うメリットは無いでしょう。
そういうわけでは無く、autotoolsの勉強なら、
パッケージ構成を見直した方が良いと思います。
57:デフォルトの名無しさん
07/04/03 12:32:21
>>56
了解しました。ちょっと見直してみます。
さらに質問で悪いのですが、
prog_SOURCES=a.c b.c c.c
とした場合、
a.c, b.c, c.cそれぞれのコンパイルに対してオプションを付けたい場合は
どのようにMakefile.amに書けばよいのでしょうか？
58:デフォルトの名無しさん
07/04/06 02:39:15
>57
>a.c, b.c, c.cそれぞれのコンパイルに対してオプションを付けたい場合は
それぞれ別々のオプションをつけたいってこと？
info の Per-Object Flags Emulation を参照。
59:デフォルトの名無しさん
07/04/07 11:08:22
>>58
ありがとうございます
60:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/06/24 22:46:03
makefileって自分で書くんじゃなくてautoconf/automakeで作るものなの？
開発途中は自分でmakefile作って、ある程度完成したらその段階で./configure でmakefile を作ってもらうほうがいいの？
63:デフォルトの名無しさん
07/06/24 22:58:31
>>62
自分で書いた方が多分楽です。
配布のときに make dist できる程度かな？
64:デフォルトの名無しさん
07/06/25 02:27:47
make distも自分で書けばいい
65:デフォルトの名無しさん
07/06/27 01:48:27
>62
複数の環境でビルドすることを考えるなら Autotools を使う方が楽だろう。
恐らく、そんな質問をしている時点では自前で Makefile を書いた方が楽だ。
66:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/09/18 01:25:02
了解です。
69:デフォルトの名無しさん
07/12/31 17:07:13
wxWidgetsをリンクするために
'wx-config --cppflags'の出力されたものを
作成ファイルのMakefile.am内オプションに追加したいのですが
いったいどうやればいいのですか？
ついでに、何度か同じことをする必要があるので
共通の変数か何かに設定できるとうれしいです。
70:デフォルトの名無しさん
08/01/26 23:26:58
automakeでcのソースをc++コンパイラでコンパイルするように指定することってできるのでしょうか？
71:デフォルトの名無しさん
08/03/09 17:46:07
HOS
72:デフォルトの名無しさん
08/03/09 17:51:09
Hyper Operating System for labors
73:デフォルトの名無しさん
08/06/12 00:21:03
Linuxでアプリ配布するなら、やっぱりAutoconf使うべきなのかな？
それとも、メジャーなディストリでビルドできればいいよくらいのスタンスなら、
自前MakefileでもOK？ みなさんどうお考えですか?
74:デフォルトの名無しさん
08/06/12 01:14:19
auto-tools は Unix 系 OS の差分を吸収するために存在するものなので,
Linux だけが対象だと auto-tools である必要はないと思われる。
「auto-tools は GNU 教への帰依の度合いを計る試金石として存在している」
と言う話を, どこかで効いたような気がするw
75:デフォルトの名無しさん
08/06/12 02:38:37
>>73
とりあえず配布してみれ．それが役に立つアプリで他のOS環境でも
動かしたいと思う人がいればきっとその人がautotoolizeしてくれるよ．
76:デフォルトの名無しさん
08/06/12 13:39:40
ビルドスクリプトとしてだけならともかく、いくつもの環境に対応しようと
#ifdefとかが絡んでくるようになると
autotoolsが枠組みを最初から用意してくれているのはそれなりに便利。
77:デフォルトの名無しさん
08/06/12 14:20:12
公開するんなら、README.1STに「誰かautotools対応して～X-<」とでも入れておくとか？