Autoconf,Automakeについて

1名無しさん@お腹いっぱい。NGNG
奥深さの前に使い方がさっぱり分からん。教えて下さい。

関連サイトは>>2

202名無しさん@お腹いっぱい。2006/12/17(日) 23:34:00
>>200 >>201
ありがとうございます。

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

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

203名無しさん@お腹いっぱい。2006/12/18(月) 17:47:27
>>202
> あと、>>200さんの方法を使った場合、libhoo.laをインストールするのが普通なのでしょうか?
> それともnoinst_LIBRARIESにした方がいいのでしょうか?

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

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

204名無しさん@お腹いっぱい。2006/12/18(月) 21:31:01
> libhoo.laはデバッグ時に必要です。
*.laって何するものなの?

205名無しさん@お腹いっぱい。2006/12/18(月) 23:43:10
>>204
> *.laって何するものなの?
$ libtool gdb hogehoge
ってやるとき、参照するライブラリが書かれているテキストファイルだと
思っているのですが、、、
識者の方ツッコミよろ。

206名無しさん@お腹いっぱい。2006/12/24(日) 20:13:53
noinst_ だったらコンビニエンスライブラリになるから、実行形式の方には最終的に静的リンクされて .la なんか不要になるはず。

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

208名無しさん@お腹いっぱい。2007/06/24(日) 05:32:53
>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_* の状態が違っているなら正常動作しなくても当然なんじゃない?

209名無しさん@お腹いっぱい。2007/06/24(日) 12:30:43
ライブラリのヘッダでconfig.hを読むってのが変だと思うけどなあ。

210名無しさん@お腹いっぱい。2007/06/24(日) 22:52:30
>>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の意味が無いというか。
普通どうやるんでしょ?

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

212名無しさん@お腹いっぱい。2007/06/25(月) 00:46:53
不要なものをhoge_config.h.inから削除するとhoge_config.hに反映されないことに気づきました。

213名無しさん@お腹いっぱい。2007/06/25(月) 17:54:39
>>210
ライブラリのヘッダファイルであるかどうかわからないtypedefをさらにtypedefって
あまり見ないような。大抵自分で型を判断してやってないか。

214名無しさん@お腹いっぱい。2007/06/25(月) 23:28:01
>>213
自分で判断というのはhogeが定義してあるのでOSはhageだとかCPUはfooだとかで
つまり4バイト数値型はhoge_intとかですか。
それがconfigureでやることではないのですか?

215名無しさん@お腹いっぱい。2007/06/26(火) 18:44:44
>>214
そのライブラリを使うアプリのconfigureでやればいいんでない?
そういう話では無いのかな

216名無しさん@お腹いっぱい。2007/07/07(土) 22:49:39
>215
ライブラリを使う側でいちいちどのマクロを定義してやる必要があるかを考えるのが面倒くさい…と思ったんだけど、
そのライブラリ用に Autoconf マクロを作ってしまうというのでその点は解決するか。
その上で、ヘッダ側では

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

しておけば OK かな。

217名無しさん@お腹いっぱい。2007/07/08(日) 20:43:24
>>216
うん。ライブラリ側で、hoge.m4作って、share/aclocal以下にインストールしてあげる。
hoge.m4はAC_DEFINE()とか、一部AH_VERBATIM()とかでconfig.h.inに追加する感じ。
結構面倒な作業になるのかもしれないけど、、、

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

218名無しさん@お腹いっぱい。2007/07/23(月) 03:24:18
CFLAGSとCPPFLAGSの違いがよくわかりません
Cプリプロセッサフラグってどういうことでしょうか?
-I/fuga/fuge/
をコンパイル時に指定したい場合、
CFLAGS=-I/fuga/fuge/
だと追加されなくて
CPPFLAGSに指定すると追加されてました。
ちなみにC++のファイルです。

219名無しさん@お腹いっぱい。2007/07/23(月) 11:01:31
なぜそこで
> Cプリプロセッサフラグ
という自分の推測が間違っているということを疑わないのか。

220名無しさん@お腹いっぱい。2007/07/23(月) 19:01:58
いや、推測じゃないです。
http://sources.redhat.com/automake/automake.html

CPPFLAGS
C/C++ preprocessor flags
となってます。

221名無しさん@お腹いっぱい。2007/07/23(月) 21:04:35
まず問いたい。
おまえはそれを見て、それが正解だと推測したわけだよな?
公式のマニュアルではなく、なぜそんな下らんもので推測したんだ?

222名無しさん@お腹いっぱい。2007/07/23(月) 22:30:52
>>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を処理するのが何か分かれば
多分理解できると思う。

223名無しさん@お腹いっぱい。2007/07/23(月) 23:56:05
ありがとうございます。
プリプロセッサの処理にコマンド指定できるんですね・・・知らんかったです。
C++でのオプションはCXXFLAGSで指定します。
サンクスでした

224名無しさん@お腹いっぱい。2007/07/24(火) 23:43:52
まず問いたい。
>という自分の推測が間違っているということを疑わないのか。
という発言が出てくるのか。
CPPFLAGSがC++用フラグだとでも自分の推測で発言したのか?w

225名無しさん@お腹いっぱい。2007/11/28(水) 22:49:28
bin_PROGRAMS=/tmp/fuga
とか出来ないんですけど、/tmp/下に生成したい場合とかどうすればいいんですか?

226名無しさん@お腹いっぱい。2007/11/29(木) 08:39:52
できるかどうかわからないけど、なぜそういうことをしたいのか
の目的がわかれば、別の解決法が出てくるかもね。

227名無しさん@お腹いっぱい。2007/11/29(木) 11:49:47
自分のホームディレクトリにソースがあったとしても、
/tmp/でmakeしたいんです。

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

228名無しさん@お腹いっぱい。2007/11/29(木) 19:43:54
>>227
> 自分のホームディレクトリにソースがあったとしても、
> /tmp/でmakeしたいんです。

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

229名無しさん@お腹いっぱい。2007/11/29(木) 23:14:50
Makefileの中身が相対パスで書かれてるみたいなので、
/tmpでmakeをしてもエラーが出るんですよね・・・
やっぱり、ソースツリーを全部/tmpにコピーってconfigure,makeした方が
早いですかね?

230名無しさん@お腹いっぱい。2007/11/30(金) 09:52:32
それは多分そのプログラムの方が悪い(autotoolsの使い方の問題)。
tmpに全部コピーした方が早そう。

231名無しさん@お腹いっぱい。2007/12/01(土) 02:00:10
普通、相対パスで書かないものですか?

232名無しさん@お腹いっぱい。2007/12/01(土) 09:41:28
>>231
srcdir や top_srcdir への相対パスなら大丈夫だけど、
# 絶対パスならabsを付ける
カレントディレクトリからのパスになってるんじゃない?

233名無しさん@お腹いっぱい。2007/12/18(火) 17:33:38
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

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

234名無しさん@お腹いっぱい。2007/12/18(火) 23:29:27
>233
my_src_dir=/home/xxx/src
prog_SOURCES=$(my_src_dir)/test.c

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

235名無しさん@お腹いっぱい。2007/12/19(水) 20:40:41
あちこちにあるファイルを集めて一つのディレクトリツリーを作りたいんですが、
なんかうまいやりかたは無いんでしょうか

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

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


236名無しさん@お腹いっぱい。2007/12/23(日) 11:19:48
>>234
ダメなんです。なぜかそういう風に展開されちゃうんですよね・・・

237sage2008/11/15(土) 00:31:39
同じソースファイルを使って、実行ファイルと共有ライブラリを
作りたいのですが、
‘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’
に解決らしき記述があるのですが、意味がわからず困っています。
どうしろと書いてあるのでしょうか?

238名無しさん@お腹いっぱい。2008/11/15(土) 11:13:40
>>237
そこの
> A workaround for this issue is
以下をていねいに読めばだいたいわからんかな?

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

239名無しさん@お腹いっぱい。2009/06/28(日) 12:09:38
linuxなんですがAutoconf,Automakeについて質問してもいいですか?

240名無しさん@お腹いっぱい。2009/08/10(月) 13:58:44
どうぞ

241名無しさん@お腹いっぱい。2011/04/12(火) 05:29:50.46
hoyu

242名無しさん@お腹いっぱい。2012/10/19(金) 00:16:16.94

243名無しさん@お腹いっぱい。2014/04/07(月) 01:55:27.82
llvm bitcodeを中間コードとしてビルドするようなmakefileをautotoolsで作れませんかね?

244名無しさん@お腹いっぱい。2014/09/25(木) 18:45:01.21
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

245名無しさん@お腹いっぱい。2015/01/03(土) 09:15:56.58
--with-* と --enable-* との使い分け方が解らない。
http://www.geocities.co.jp/SiliconValley-Oakland/3432/man/autoconf/autoconf-ja_9.html
を読んでも解らない。

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

246名無しさん@お腹いっぱい。2015/01/03(土) 21:25:10.13
ぐぐったら入力途中で候補にautoconf with vs enableというのが出てきたので
その結果を見てみたらいろいろと議論はあるようだ。

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

247名無しさん@お腹いっぱい。2015/01/03(土) 23:36:29.26
>>246
構文はそっくりだけど意味は違うよ、適切に使い分けてね
って事かな…?

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

248名無しさん@お腹いっぱい。2015/01/04(日) 00:09:09.26
英語の意味通りですな

249名無しさん@お腹いっぱい。2015/01/06(火) 19:37:27.79
キター!

From: Stefano Lattarini <stefano.lattarini@gmail.com>
To: Automake List <automake@gnu.org>
Cc: info-gnu@gnu.org, autotools-announce@gnu.org
日付: 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

250名無しさん@お腹いっぱい。2017/06/25(日) 07:39:08.66
2年ぶり!

From: Mathieu Lirzin <mthl@gnu.org>
To: <automake@gnu.org>
Subject: GNU Automake 1.15.1 released
Date: Mon, 19 Jun 2017 22:50:34 +0200
Message-ID: <87shivem79.fsf@gnu.org>

We are pleased to announce the GNU Automake 1.15.1 maintenance release.

251名無しさん@お腹いっぱい。2017/12/29(金) 07:37:16.28
誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。

グーグル検索⇒『宮本のゴウリエセレレ』

CAEY39R21B

252名無しさん@お腹いっぱい。2018/05/22(火) 06:13:54.01
知り合いから教えてもらったパソコン一台でお金持ちになれるやり方
時間がある方はみてもいいかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』

CGFTL

新着レスの表示
レスを投稿する