Autoconf/Automake/Libtool

使いこなしてｶｯｸｲｲ！

あたかも自分がすごいプログラマになったかのように思えるのが良いね。

hello world!!のCプログラムをMakefileからすべて用意して、
/srcだの/binだのとりあえず作るようにして、無意味にいろいろライブラリ指定して、
そりゃもう、宇宙から来た人のような紀文。

誰か発展させろよこのスレ

おーとこんふ

設定ファイルの為のツールというのが解せない
素直にMakeあたりの機能を拡張した方がよくね？

UNIXの精神とやらにそぐわないのかな

いや、autoconfを使い倒すことこそGNUへの忠誠心の表れだろう。
と、マニュアルには書いてある。

>>6
WebブラウザとHTMLエディタを一緒にするようなもんか

今どきのマーはレガシーなautotoolなんて知らないんじゃないの？

>>6
違うだろ
makeファイル自動生成ツールだろ

こいつらキライ
高々ビルドにこんな労力が必要なのは間違ってる

じゃあ使わなければいい

>>11
autoconfが悪いんじゃない。
悪いのはUNIX環境の統一の無さ。

まあその分、autotoolsが動けばどんな環境でもMakefileが通るようにはできるけどね。
もちろん、実際にプログラムが動くかどうかは別の話だけど。

4000円は高い
もっと安い本は無いものか

英語だと最新版だし、タダだよ

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は
成功するのですが自動生成する方法はないでしょうか？

>>17
とりあえず
$ autoreconf -vfi
とかしてみたり、
$ autoupdate
などで、autoconf-2.5xに対応してみては？

>>18
やってみましたが効果なしです。

>>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

>>20
どうやらconfigure.ac(configure.in)でAM_INIT_AUTOMAKE
の後にAC_CONFIG_AUX_DIRを書いていたのがいけなかったみ
たいです。
下のサイトにautoconf2.5xでは
「AC_INAC_INITの直後にAM_INIT_AUTOMAKE書く。」
と書いてあったので、それを実践していました。
http://www.saiin.net/~silphire/tips/autoconf.html

CppUnit::TestFactoryRegistry::getRegistry().makeTest()
を使うとテストが二回り行われてしまします。
それを防ぎたいのですけど何か設定とかあるのですか？

いま再び読み始めたのでageとこ
GNU Make の後に読んでるからかやっと意味がわかった

前読んだときは書いてあることがまったくわからんかったのに・・・
「./configure;make;make install;」って今までおまじないでしかなかったのに・・・

みんなすごいね、中の人が何やってるか理解してつかってるの？

まぁ、そこら辺はどのアプリでも殆ど同じだからね。

良スレ上げ

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 以降の処理はやってない気がするのですが？？

なにか勘違いしているのだろうか？？？

>>26
バージョンが古いのでは？
automake-1.9以降はそうなっていない。

おお、さんくす
確認してみたら automake-1.6 だった。MacOSX 10.4.8
そうか、古いのか・・・

automakeはPerlスクリプトなのね。autoconfはshスクリプトだし
このあたりのスクリプトの集合体なわけですか、なるほど

単体テストの骨組みもあるんだね、単純に配布ツールだと思ってた

>>30
autotest関係はいまだ不安定かも。(2.60では大丈夫なのかな？)
というか、テスト全部にconfigure.ac書くのはめんどくさいかも。

不安定っていうのは、仕様変更が今後もありうるかもって意味であって、
動作が不安定ってわけじゃないので、安心してください。

あるプログラムの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は、何に何を設定すればいいのでしょうか？

>>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)
にインストールされてる。

>>33
ありがとうございました。
助かりました。

メモ：
configure.in のひな形 configure.scan は autoscan で作れる。
autoscan はPerlのスクリプトである。
どのような基準でひな形を生成しているかは Perlスクリプトを読まなければならない、多分

Perl わかんねからそっちの勉強しよ

>>35
> どのような基準でひな形を生成しているかは Perlスクリプトを読まなければならない、多分

info 読んだ方が楽だと思うけど、、、
後は、適当なソース書いて、autoscanしてconfigure.scanを見るとか。

おお、さんくす

＞info 読んだ方が楽だと思うけど、、、
確かに info autoscan 見たら詳しく書いてあった。
man autoscan だけしか見てなかったから動作基準が解らなかった。
# man の SEE ALSO 項目なんて全然意識してなかった

いままで
＞後は、適当なソース書いて、autoscanしてconfigure.scanを見るとか。
コレしてたんだけど in/out の動作原理が解らなかった.

ありがとう

めも：
Autoconf/Automake/Libtool　この本は今イチよく解らない。でも代わりの良い本は解らない

ググったかんじでは
Automakeでmakeする
ttp://www.02.246.ne.jp/~torutk/cxx/automake/automake.html

ここが解りやすかった。あと マニュアルの日本語訳
ttp://www.geocities.jp/fut_nis/

Autotools の使い方について質問させてください。
フォルダ配置がこのようにようになっていて

main
  ･ configure.ac
  ･ Makefile.am
  --src folder
      ･ Makefile.am
      ･ xxx.c
  --include folder

configure.ac, Makefile.am それぞれに
次レスのような内容を記述しています。

make をした後コンパイルには成功するのですが
なぜかオブジェクトファイルがどこにも見つからずライブラリが作れない状態です (´･ω･`)ｼｮﾎﾞｰﾝ
コンパイルエラーは表示されないのでコンパイルには成功してると思うのですが･･･
どなたか対処法分かる方いませんか？

------- 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

age

>>39
> なぜかオブジェクトファイルがどこにも見つからずライブラリが作れない状態です (´･ω･`)ｼｮﾎﾞｰﾝ

.libs 以下にできてるとか、、、というか、libtoolを使えば？

>>40
一応確認するが、このコピペはconfigure.acとMakefile.amだよな?
configure.inとMakefile.inじゃなくて。
前者はともかく、後者は違っているとダメだと思うぞ。

で、それはそれとして。
make clean all >& make.log とでもしてログを吐き、
ログの中のコンパイルしている箇所を観察すれば、
どこにオブジェクトファイルを出力したのか(あるいはコンパイル自体していないのか)
わかるはず。

>>42
.libs を探してみたのですが、ありませんでした。
autotoolsは今でもいっぱいいっぱいなので、
libtool はとりあえず後回しで・・・orz

>>43
失礼しました。Makefile.amです。
ﾛｸﾞも見てみたのですが、何が原因か全く分かりませんヽ(`Д´)ﾉｳﾜｧｧｧﾝ


このままだと埒が明かないので、
自分がコンパイルしようとしたサンプルプログラムをアップします。
http://wonder.bms.ms/tower/bin/sugoiuploader/img/037.zip
（>>39-40から内容を少し変えてあります）

make.log や Makefile も残しておいたので、
原因が分かる方がいたらほんとに教えてください。(人∀･)ﾀﾉﾑ

また、理由はよく分からないのですが gcc コマンドを手打ちして
オブジェクトファイルを作れば、メイクには成功します。
自分の実行したコマンドは build にあります。

>>44
取れないので。取れた人よろしく。

すいません。あぷろだの調子が悪いかもしれません。
別の所にアップし直しました。

http://gamdev.org/up/img/8499.zip

>>46
src/Makefile.amの内容が40の（src/Makefile.in）とずいぶん違うようだが...

とりあえず実行権限が付与されてあるべきファイルで実際には付与されていないのがいくつかある
xxx/configure
xxx/depcomp

xxx/depcompを消してautomakeで作りなおしたらうまくいったよ

>>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
な環境。

ﾟ･*:.｡..｡.:*･゜ヽ( ´∀`)人(´∀` )ノ･゜ﾟ･*:.｡..｡.:*

>>47
出来ました！
実行権限の問題だったのですね
ありがとうございます。

>>46
バージョンの方も指定するようにしました。
いろいろとありがとうございます。

ﾟ･*:.｡..｡.:*･゜ヽ( ´∀`)人(´∀` )ノ･゜ﾟ･*:.｡..｡.:*

↑ >>46ではなく>>48です^^

Makefile.amを使ってMakefileを作っています。
ソースがincludeしているヘッダファイルが修正されたときに、そのソースを自動で
コンパイルし直す様なMakefileを作るにはどうすれば良いでしょうか？

>>51
普通にそのようなMakefileができますが...

すみません。
自動でやってくれていました。

依存してないファイルを修正して試してました。
依存している物で試したら上手く処理してくれましたorz。

質問です。
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

このように書かなくてはならないのでしょうか？

>>55
根本的に、autoconf、libtoolは移植性
automakeはパッケージ作成のためなので、
外部のオブジェクトとリンクするパッケージでは、
autotoolsを使うメリットは無いでしょう。

そういうわけでは無く、autotoolsの勉強なら、
パッケージ構成を見直した方が良いと思います。

>>56
了解しました。ちょっと見直してみます。
さらに質問で悪いのですが、
prog_SOURCES=a.c b.c c.c
とした場合、
a.c, b.c, c.cそれぞれのコンパイルに対してオプションを付けたい場合は
どのようにMakefile.amに書けばよいのでしょうか？

>57
>a.c, b.c, c.cそれぞれのコンパイルに対してオプションを付けたい場合は
それぞれ別々のオプションをつけたいってこと？
info の Per-Object Flags Emulation を参照。

>>58
ありがとうございます

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にある
ファイルを記述した方が管理が楽だろうと考えているのですが・・・

>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

で、いけるんじゃない？

makefileって自分で書くんじゃなくてautoconf/automakeで作るものなの？
開発途中は自分でmakefile作って、ある程度完成したらその段階で./configure でmakefile を作ってもらうほうがいいの？

>>62
自分で書いた方が多分楽です。
配布のときに make dist できる程度かな？

make distも自分で書けばいい

>62
複数の環境でビルドすることを考えるなら Autotools を使う方が楽だろう。
恐らく、そんな質問をしている時点では自前で Makefile を書いた方が楽だ。

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と同じ効果しか得られません。
どうしたらよいか教えていただけませんか？

>>66
CFLAGSなどはユーザ(パッケージを使う人)が制御するものなので、
パッケージメンテナが強制してはならない。
Makefile.amはパッケージメンテナが書くものなので、
その中で最適化オプションを強制するのは厳禁。
これを体現するため、ユーザ指定のCFLAGSは必ず最後に付加されることになってる。
詳しくは automake.info の FAQ の "Flag Variables Ordering" でも読んで。

回避するハックがあるかどうかは知らないが、お勧めしない。

ユーザとしてその場で行いたいだけなら、次のようにすればOK。

cd test; make CFLAGS=-O0 b.o

了解です。

wxWidgetsをリンクするために
'wx-config --cppflags'の出力されたものを
作成ファイルのMakefile.am内オプションに追加したいのですが
いったいどうやればいいのですか？

ついでに、何度か同じことをする必要があるので
共通の変数か何かに設定できるとうれしいです。

automakeでcのソースをc++コンパイラでコンパイルするように指定することってできるのでしょうか？

HOS

Hyper Operating System for labors

Linuxでアプリ配布するなら、やっぱりAutoconf使うべきなのかな？
それとも、メジャーなディストリでビルドできればいいよくらいのスタンスなら、
自前MakefileでもOK？　みなさんどうお考えですか?

auto-tools は Unix 系 OS の差分を吸収するために存在するものなので,
Linux だけが対象だと auto-tools である必要はないと思われる。

「auto-tools は GNU 教への帰依の度合いを計る試金石として存在している」
と言う話を, どこかで効いたような気がするw

>>73
とりあえず配布してみれ．それが役に立つアプリで他のOS環境でも
動かしたいと思う人がいればきっとその人がautotoolizeしてくれるよ．

ビルドスクリプトとしてだけならともかく、いくつもの環境に対応しようと
#ifdefとかが絡んでくるようになると
autotoolsが枠組みを最初から用意してくれているのはそれなりに便利。

公開するんなら、README.1STに「誰かautotools対応して〜X-<」とでも入れておくとか？

autoconfでc++のライブラリの有無をチェックしたいのですが、
AC_CHECK_LIB だとうまくいきません。（名前空間やname manglingの影響？）
どうやるのがよいでしょうか？

>78
多分 AC_LANG 辺りじゃないかと思うが、どううまくいかないのか書かないと分からないと思われ。
config.log くらいは確認してる？

>>79

あ、うまくいかないというのは、ライブラリはインストールされているのに、
ないと判断されてしまうということです。
関数をmain でやったら、うまくいってるっぽいですが、これでいいんですかね？

>80
だからさ、エスパーきぼんぬしたいんじゃなければ何をどうやってどうなったかもう少しきちんと書こうぜ。
これで、第三者がまともな回答ができると思ってんの？
このライブラリの有無の判別がしたくて、configure.ac にはこう書いて、config.log の該当部分ではこんなコードと
出力になっています、まで書いて当然レベルじゃね？
もっとも config.log の該当部分のソースとコンパイラ(orリンカ)が出力してるエラーを見れば質問するまでもなく
理由と対処は見えると思うけど。

>>81
80みたいのはもともと脳味噌壊れてるので言ってもわからん気がするぞ。

質問です。clock_gettime() という関数の存在を判定したいのですが、

AC_CHECK_FUNCS([clock_gettime])

とAC_CHECK_FUNCSを使ってみたのですが、発見してくれません。

AC_CHECK_DECL を試してみたのですがこちらも駄目でした。

実際には、手元のLinux （CentOS 5） では

$ grep clock_gettime /usr/include/time.h
extern int clock_gettime (clockid_t __clock_id, struct timespec *__tp) __THROW;

と存在しています。

config.log を見てみたんですが、判定に使っている conftest.c で、<time.h> をインクルード
してないのが理由のようです。 clock_gettime()を発見してもらうには
どうしたらいいのでしょうか？

すいませんautocnofのバージョン貼り忘れました

$ autoconf --version
autoconf (GNU Autoconf) 2.62

>83
AC_TRY_COMPILE 使ってヘッダ指定すればいいんじゃね？

>>85
ども
なんかマニュアル見たらobsoleteだって書いてあったので、
↓のようにしたらできました。ありがとうございました。

AC_COMPILE_IFELSE(
　[AC_LANG_PROGRAM([[ #include<time.h> ]],
　　　[[(void) &clock_gettime;]])],
　　　[AC_DEFINE([HAVE_CLOCK_GETTIME],
　　　　　　　　　[1],
　　　　　　　　　[Whether clock_gettime() exists.])],
　　　[])

こやつめｗ