06/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:デフォルトの名無しさん
06/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書く。」
と書いてあったので、それを実践していました。
URLﾘﾝｸ(www.saiin.net)
22:デフォルトの名無しさん
06/08/15 14:09:10
CppUnit::TestFactoryRegistry::getRegistry().makeTest()
を使うとテストが二回り行われてしまします。
それを防ぎたいのですけど何か設定とかあるのですか？
23:デフォルトの名無しさん
06/10/31 01:42:58
いま再び読み始めたのでageとこ
GNU Make の後に読んでるからかやっと意味がわかった
前読んだときは書いてあることがまったくわからんかったのに・・・
「./configure;make;make install;」って今までおまじないでしかなかったのに・・・
みんなすごいね、中の人が何やってるか理解してつかってるの？
24:デフォルトの名無しさん
06/10/31 03:02:37
まぁ、そこら辺はどのアプリでも殆ど同じだからね。
25:デフォルトの名無しさん
06/11/01 01:34:59
良スレ上げ
26:23
06/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:デフォルトの名無しさん
06/11/06 21:16:27
>>26
バージョンが古いのでは？
automake-1.9以降はそうなっていない。
28:23
06/11/06 22:13:26
おお、さんくす
確認してみたら automake-1.6 だった。MacOSX 10.4.8
そうか、古いのか・・・
29:23
06/11/07 12:32:13
automakeはPerlスクリプトなのね。autoconfはshスクリプトだし
このあたりのスクリプトの集合体なわけですか、なるほど
30:23
06/11/16 14:03:14
単体テストの骨組みもあるんだね、単純に配布ツールだと思ってた
31:デフォルトの名無しさん
06/11/16 21:27:33
>>30
autotest関係はいまだ不安定かも。(2.60では大丈夫なのかな？)
というか、テスト全部にconfigure.ac書くのはめんどくさいかも。
不安定っていうのは、仕様変更が今後もありうるかもって意味であって、
動作が不安定ってわけじゃないので、安心してください。
32:デフォルトの名無しさん
06/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:デフォルトの名無しさん
06/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:デフォルトの名無しさん
06/11/17 23:50:25
>>33
ありがとうございました。
助かりました。
35:23
06/11/18 21:03:37
メモ：
configure.in のひな形 configure.scan は autoscan で作れる。
autoscan はPerlのスクリプトである。
どのような基準でひな形を生成しているかは Perlスクリプトを読まなければならない、多分
Perl わかんねからそっちの勉強しよ
36:デフォルトの名無しさん
06/11/19 09:34:20
>>35
> どのような基準でひな形を生成しているかは Perlスクリプトを読まなければならない、多分
info 読んだ方が楽だと思うけど、、、
後は、適当なソース書いて、autoscanしてconfigure.scanを見るとか。
37:23
06/11/19 10:50:00
おお、さんくす
＞info 読んだ方が楽だと思うけど、、、
確かに info autoscan 見たら詳しく書いてあった。
man autoscan だけしか見てなかったから動作基準が解らなかった。
# man の SEE ALSO 項目なんて全然意識してなかった
いままで
＞後は、適当なソース書いて、autoscanしてconfigure.scanを見るとか。
コレしてたんだけど in/out の動作原理が解らなかった.
ありがとう
38:23
06/11/21 22:44:16
めも：
Autoconf/Automake/Libtool この本は今イチよく解らない。でも代わりの良い本は解らない
ググったかんじでは
Automakeでmakeする
URLﾘﾝｸ(www.02.246.ne.jp)
ここが解りやすかった。あと マニュアルの日本語訳
URLﾘﾝｸ(www.geocities.jp)
39:デフォルトの名無しさん
06/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:続き
06/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:デフォルトの名無しさん
06/12/30 02:32:27
age
42:デフォルトの名無しさん
06/12/30 10:04:53
>>39
> なぜかオブジェクトファイルがどこにも見つからずライブラリが作れない状態です (´･ω･`)ｼｮﾎﾞｰﾝ
.libs 以下にできてるとか、、、というか、libtoolを使えば？
43:デフォルトの名無しさん
06/12/30 14:00:36
>>40
一応確認するが、このコピペはconfigure.acとMakefile.amだよな?
configure.inとMakefile.inじゃなくて。
前者はともかく、後者は違っているとダメだと思うぞ。
で、それはそれとして。
make clean all >& make.log とでもしてログを吐き、
ログの中のコンパイルしている箇所を観察すれば、
どこにオブジェクトファイルを出力したのか(あるいはコンパイル自体していないのか)
わかるはず。
44:デフォルトの名無しさん
06/12/30 16:36:14
>>42
.libs を探してみたのですが、ありませんでした。
autotoolsは今でもいっぱいいっぱいなので、
libtool はとりあえず後回しで・・・orz
>>43
失礼しました。Makefile.amです。
ﾛｸﾞも見てみたのですが、何が原因か全く分かりませんヽ(`Д´)ﾉｳﾜｧｧｧﾝ
このままだと埒が明かないので、
自分がコンパイルしようとしたサンプルプログラムをアップします。
URLﾘﾝｸ(wonder.bms.ms)
（>>39-40から内容を少し変えてあります）
make.log や Makefile も残しておいたので、
原因が分かる方がいたらほんとに教えてください。(人∀･)ﾀﾉﾑ
また、理由はよく分からないのですが gcc コマンドを手打ちして
オブジェクトファイルを作れば、メイクには成功します。
自分の実行したコマンドは build にあります。
45:デフォルトの名無しさん
06/12/30 18:40:59
>>44
取れないので。取れた人よろしく。
46:44
06/12/31 01:55:48
すいません。あぷろだの調子が悪いかもしれません。
別の所にアップし直しました。
URLﾘﾝｸ(gamdev.org)
47:デフォルトの名無しさん
06/12/31 02:42:31
>>46
src/Makefile.amの内容が40の（src/Makefile.in）とずいぶん違うようだが...
とりあえず実行権限が付与されてあるべきファイルで実際には付与されていないのがいくつかある
xxx/configure
xxx/depcomp
xxx/depcompを消してautomakeで作りなおしたらうまくいったよ
48:デフォルトの名無しさん
06/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:デフォルトの名無しさん
06/12/31 14:46:53
ﾟ･*:.｡..｡.:*･゜ヽ( ´∀`)人(´∀` )ノ･゜ﾟ･*:.｡..｡.:*
>>47
出来ました！
実行権限の問題だったのですね
ありがとうございます。
>>46
バージョンの方も指定するようにしました。
いろいろとありがとうございます。
ﾟ･*:.｡..｡.:*･゜ヽ( ´∀`)人(´∀` )ノ･゜ﾟ･*:.｡..｡.:*
50:デフォルトの名無しさん
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-<」とでも入れておくとか？