Autoconf,Automakeについて

>>199
とりあえず、、、試してみた。
topdirのMakefile.am (プログラム名はhooと仮定)

SUBDIRS = others
bin_PROGRAMS = foo
foo_SOURCES = main.c
foo_LDDADD = $(top_builddir)/othes/libhoo.la
foo_CFLAGS = -I$(top_srcdir)/others
foo_LDFLAGS = -L$(top_builddir)/others -lhoo

othersのMakefile.am

lib_LTLIBRARIES = libhoo.la
libhoo_la_SOURCES = hoo.c hoo.h

configure.ac

AC_PREREQ(2.61)
AC_INIT([foo], [0.0.0], [[email protected]])
AC_CONFIG_SRCDIR([main.c])
AC_CONFIG_HEADER([config.h])
AM_INIT_AUTOMAKE([foreign])
AC_PROG_CC
AC_PROG_LIBTOOL
AC_CONFIG_FILES([Makefile
others/Makefile])
AC_OUTPUT

>>199
具体的もなにもmain.cのあるディレクトリのMakefile.amで
hoge_SOURCES=main.c others/hoo.h others/hoo.cpp
するだけだよ
othersにあるファイルも同じように扱えるようになったみたいなので
わざわざライブラリにまとめる必要はない

>>200 >>201
ありがとうございます。

確かにmainのあるディレクトリでothers/hoge.cppと指定すれば出来ました。
しかし、サブディレクトリに物凄くファイルがあるので、階層別にMakefileを作り、ライブラリにしたほうが管理しやすそうに思えます。

あと、>>200さんの方法を使った場合、libhoo.laをインストールするのが普通なのでしょうか？
それともnoinst_LIBRARIESにした方がいいのでしょうか？

>>202
> あと、>>200さんの方法を使った場合、libhoo.laをインストールするのが普通なのでしょうか？
> それともnoinst_LIBRARIESにした方がいいのでしょうか？

ほかで利用するならインストールするけど、そうでなければ
デフォルトでstaticにしないと不味いかもしれません。
他で使うなら、include_HEADERSにヘッダを書かなきゃだめですが、、、

判断できない場合は、とりあえずインストールするのが無難です。
# libhoo.laはデバッグ時に必要です。

> libhoo.laはデバッグ時に必要です。
*.laって何するものなの?

>>204
> *.laって何するものなの?
$ libtool gdb hogehoge
ってやるとき、参照するライブラリが書かれているテキストファイルだと
思っているのですが、、、
識者の方ツッコミよろ。

noinst_ だったらコンビニエンスライブラリになるから、実行形式の方には最終的に静的リンクされて .la なんか不要になるはず。

AC_CHECK_HEADERなどで宣言されるHAVE_*の先頭に識別子をつけることはできる？
#define HOGE_HAVE_MEMORY_H
となるような。
hoge_config.hをライブラリのヘッダーから読み込もうと思っているのですが
ライブラリを使う側にHAVE_*が影響してしまうので
ライブラリのコンパイル後に消すか、名前を変えるかしたい。
しかし、ライブラリヘッダーが提供する構造体要素の型をHAVE_*を見て切り替えたいので
単純にconfigヘッダーをインストールしないというわけにもいかず。

>207
とりあえず、autoconf-2.61 でだけど。
本論と関係ないけど、AC_CHECK_HEADER は HAVE_* を自動で定義してくれなくて、AC_CHECK_HEADERS が、HAVE_* を自動で定義してくれるような。

で、

AC_CHECK_HEADER(test.h, AC_DEFINE(HOGE_HAVE_TEST_H, [], [Define to 1 if you have the <test.h> header file.]))

みたいな感じで自前で書けばいいと思う。autoheader も拾ってくれてるみたいだし。
デフォルトで定義されてしまう分(configure 自体に使用される)についても名前を差し替えたい場合には、_AC_INCLUDES_DEFAULT_REQUIREMENTS か
AC_INCLUDES_DEFAULT の再定義が必要。

ここまで書いて思ったんだけどさ、ライブラリ作成環境と実行環境で HAVE_* の状態が違っているなら正常動作しなくても当然なんじゃない？

ライブラリのヘッダでconfig.hを読むってのが変だと思うけどなあ。

>>208
どうも。
AC_CHECK_HEADERSで自己定義して、定義しても自動ででてるーと思ってました。
AC_CHECK_HEADERならでないのですか。
>>209
例えば、
#if HAVE_INTTYPES_H
#include <inttypes.h>
#elif HAVE_STDINT_H
#include <stdint.h>
#else
# ..... 自己定義
#endif
#if HAVE_SYS_STYPES_H
#.......略
typedef size_t my_size_t ;
typedef uint32_t my_uint32_t ;
typedef struct libraryargs {
　my_size_t length;
　my_uint32_t data;
} libraryargs;
DECLARE_EXPORT my_bool_t library_function(libraryargs *args);
というのがあると、size_tやuint32_tが実際なに型なのかconfigureで作ると思っていて
その結果をライブラリコンパイル時に使っているので
ライブラリを使う側も同じ型を使って欲しいと思うんです。
それをまた#ifdef _WIN32でやっているとconfigureの意味が無いというか。
普通どうやるんでしょ？

>>208
>ライブラリ作成環境と実行環境で HAVE_* の状態が違っているなら正常動作しなくても当然なんじゃない？
動作というより、他のプログラムが使う可能性のあるマクロ名を汚染してしまうのが嫌。
Cだから仕方が無いといえばそうだけど、せめてHOGE_*にしてあげたい。

不要なものをhoge_config.h.inから削除するとhoge_config.hに反映されないことに気づきました。

>>210
ライブラリのヘッダファイルであるかどうかわからないtypedefをさらにtypedefって
あまり見ないような。大抵自分で型を判断してやってないか。

>>213
自分で判断というのはhogeが定義してあるのでOSはhageだとかCPUはfooだとかで
つまり4バイト数値型はhoge_intとかですか。
それがconfigureでやることではないのですか？

>>214
そのライブラリを使うアプリのconfigureでやればいいんでない？
そういう話では無いのかな

>215
ライブラリを使う側でいちいちどのマクロを定義してやる必要があるかを考えるのが面倒くさい…と思ったんだけど、
そのライブラリ用に Autoconf マクロを作ってしまうというのでその点は解決するか。
その上で、ヘッダ側では

#ifdef HAVE_CONFIG_H
#include <config.h>
#endif

しておけば OK かな。

>>216
うん。ライブラリ側で、hoge.m4作って、share/aclocal以下にインストールしてあげる。
hoge.m4はAC_DEFINE()とか、一部AH_VERBATIM()とかでconfig.h.inに追加する感じ。
結構面倒な作業になるのかもしれないけど、、、

まあ、hoge_config.h.inから作るってのも解決方法の一つかもしれないけど、
どっちが良いかはよく分からないです。

CFLAGSとCPPFLAGSの違いがよくわかりません
Cプリプロセッサフラグってどういうことでしょうか？
-I/fuga/fuge/
をコンパイル時に指定したい場合、
CFLAGS=-I/fuga/fuge/
だと追加されなくて
CPPFLAGSに指定すると追加されてました。
ちなみにC++のファイルです。

なぜそこで
> Cプリプロセッサフラグ
という自分の推測が間違っているということを疑わないのか。

いや、推測じゃないです。
http://sources.redhat.com/automake/automake.html
で
CPPFLAGS
C/C++ preprocessor flags
となってます。

まず問いたい。
おまえはそれを見て、それが正解だと推測したわけだよな？
公式のマニュアルではなく、なぜそんな下らんもので推測したんだ？

>>221
いや、これ、infoのhtml版だから、ほぼ正式と思っていいと思う。

>>218
http://sources.redhat.com/automake/automake.html#C_002b_002b-Support
CXXFLAGSがC++のときのCFLAGSみたいなもの

プリプロセッサとは、
http://e-words.jp/w/E38397E383AAE38397E383ADE382BBE38383E382B5.html
これでも読んでくれ。#includeを処理するのが何か分かれば
多分理解できると思う。

ありがとうございます。
プリプロセッサの処理にコマンド指定できるんですね・・・知らんかったです。
C++でのオプションはCXXFLAGSで指定します。
サンクスでした

まず問いたい。
>という自分の推測が間違っているということを疑わないのか。
という発言が出てくるのか。
CPPFLAGSがC++用フラグだとでも自分の推測で発言したのか？w

bin_PROGRAMS=/tmp/fuga
とか出来ないんですけど、/tmp/下に生成したい場合とかどうすればいいんですか？

できるかどうかわからないけど、なぜそういうことをしたいのか
の目的がわかれば、別の解決法が出てくるかもね。

自分のホームディレクトリにソースがあったとしても、
/tmp/でmakeしたいんです。

/home/my/src/"ここにソースがある"
けど、makeを叩くことで、
/tmp/でビルドさせたいんです。

>>227
> 自分のホームディレクトリにソースがあったとしても、
> /tmp/でmakeしたいんです。

/tmp で/home/my/src/configure
すれば、/tmp以下にMakefileができると思うけど。
そういう話ではない？

Makefileの中身が相対パスで書かれてるみたいなので、
/tmpでmakeをしてもエラーが出るんですよね・・・
やっぱり、ソースツリーを全部/tmpにコピーってconfigure,makeした方が
早いですかね？

それは多分そのプログラムの方が悪い(autotoolsの使い方の問題)。
tmpに全部コピーした方が早そう。

普通、相対パスで書かないものですか？

>>231
srcdir や top_srcdir への相対パスなら大丈夫だけど、
# 絶対パスならabsを付ける
カレントディレクトリからのパスになってるんじゃない？

prog_SOURCESにカレントディレクトリ以外のファイルを以下のように指定すると

my_src_dir=/home/xxx/src/
prog_SOURCES=$(my_src_dir)test.c

生成されるMakefileに

include ./$(DEPDIR)/prog-$(my_src_dir)test.Po

という記述がされて、

./deps/prog-/home/xxx/src/test.Po

を見に行ってしまいエラーになってしまいます。
回避する方法ってありますか？

>233
my_src_dir=/home/xxx/src
prog_SOURCES=$(my_src_dir)/test.c

だったら通ったりしない？
って絶対パスじゃないと駄目なの？そーいうのはソースじゃなくてライブラリにしないか？

あちこちにあるファイルを集めて一つのディレクトリツリーを作りたいんですが、
なんかうまいやりかたは無いんでしょうか

a/b/c/hoge : d/e/hoge
install ...
a/b/c/huga : f/g/huga
...

とか延々と書くのが面倒臭いんです...

>>234
ダメなんです。なぜかそういう風に展開されちゃうんですよね・・・

同じソースファイルを使って、実行ファイルと共有ライブラリを
作りたいのですが、
‘created with both libtool and without’エラーが吐かれて、
うまくいきません。

http://www.gnu.org/software/automake/manual/html_node/Libtool-Issues.html
の8.3.9.2 Objects ‘created with both libtool and without’
に解決らしき記述があるのですが、意味がわからず困っています。
どうしろと書いてあるのでしょうか？

>>237
そこの
> A workaround for this issue is
以下をていねいに読めばだいたいわからんかな？

prog_CFLAGS = $(AM_CFLAGS)
を追加して、副作用として prog.c と foo.c が prog-prog.o と prog-foo.o に
コンパイルされるようにする（そうすることで、ライブラリのほうの
オブジェクトファイルと、名前がぶつからないようにする）、とある。

linuxなんですがAutoconf,Automakeについて質問してもいいですか？

どうぞ

hoyu

http://shop.oreilly.com/product/0636920025108.do
良いか？

llvm bitcodeを中間コードとしてビルドするようなmakefileをautotoolsで作れませんかね？

Autotools: A Practitioner's Guide to GNU Autoconf, Automake, and Libtool
ttp://books.google.co.jp/books?id=HBbKghM2fGYC&dq=Autotools&hl=ja&source=gbs_navlinks_s

--with-* と --enable-* との使い分け方が解らない。
http://www.geocities.co.jp/SiliconValley-Oakland/3432/man/autoconf/autoconf-ja_9.html
を読んでも解らない。

どっちを使っても良いのかな?

ぐぐったら入力途中で候補にautoconf with vs enableというのが出てきたので
その結果を見てみたらいろいろと議論はあるようだ。

https://mail.python.org/pipermail/python-dev/2001-January/011991.html
ここの解説だと、機能の有無を決めるのにenable、依存するパッケージとかの
指定にwithを使うという感じみたい。それでも例外もあるようだ。

>>246
構文はそっくりだけど意味は違うよ、適切に使い分けてね
って事かな…?

今回はpackageの有無で機能を切り替えるので--with-*を使うことにするわ、サンクス!

英語の意味通りですな

キター!

From: Stefano Lattarini <[email protected]>
To: Automake List <[email protected]>
Cc: [email protected], [email protected]
日付: 2015年1月6日 19:19
件名: GNU Automake 1.15 released

We are pleased to announce the GNU Automake 1.15 minor release.

(snip)

Download here:

ftp://ftp.gnu.org/gnu/automake/automake-1.15.tar.gz
ftp://ftp.gnu.org/gnu/automake/automake-1.15.tar.xz