X

Autoconf,Automakeについて

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

関連サイトは>>2
0133名無しさん＠お腹いっぱい。
垢版 |
NGNG
教えてください。以下のようなソースがあるとして、
・main.cc
　　#ifdef HAVE_DIRECTX
　　#include "directx_test.h"
　　#else
　　#include "opengl_test.h"
　　#endif
・directx_test.h directx_test.cc
・opengl_test.h opengl_test.cc

./configure --enable-openglした場合に
必要なソースだけ選択的にcompile, linkさせるって
どのようにMakefile.amを書けば良いでしょうか？

状況に応じて依存関係が変化してくれると助かるのですが
・directx使用時 main_SOURCES = main.cc directx_test.h directx_test.cc
・opengl使用時 main_SOURCES = main.cc opengl_test.h opengl_test.cc

ほかに、directx用とopengl用にdirectoryとMakefile.amを二つ用意するのも手だと思いますが、
top directoryで./configure, makeした場合、linuxでcompileできない
directxに関係するソースを無視させるにはどうやったら良いでしょうか？
0134名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>133
--enable-openglのときにHAVE_DIRECTXがundefされるんなら

bin_PROGRAMS = hoge
hoge_SOURCES = main.cc
if HAVE_DIRECTX
hoge_SOURCES += directx_test.h directx_test.cc
else
hoge_SOURCES += opengl_test.h opengl_test.cc
endif

でできんかな？
info automakeのBuilding a programのConditional compilations
あたり。
0135133
垢版 |
NGNG
>>134
キモはAM_CONDITIONALとifの組み合わせだったのですね。
やりたいことが実現できてすっきりです。ありがとうございます。
0136名無しさん＠お腹いっぱい。
垢版 |
NGNG
あるプログラムは C、あるプログラムは シェルスクリプト、あるプログラムは Perl を使って書かれた
パッケージを autoconf, automake でインスコさせたい時、
シェルスクリプトとか Perl に関する指示はどう出せばいいんですか?
0139名無しさん＠お腹いっぱい。
垢版 |
NGNG
AC_CHECK_SIZEOF(wchar_t) の結果を Makefile(.am) 内で知りたいのだが、
何かうまい方法はないもんですかね・・・。

（wchar_t のサイズが Linux と Cygwin で違うから、コンパイルするファイルを
振り分けたい、というのが動機です）
0141139
垢版 |
NGNG
>>140
レスどうもでつ。
結局 AC_CANONICAL_HOST で逃げることにしますた。
0143名無しさん＠お腹いっぱい。
垢版 |
2005/05/07(土) 09:54:27
-lhogeでstatic-linkさせる方法を教えて下さい。
0144名無しさん＠お腹いっぱい。
垢版 |
2005/05/07(土) 12:38:59
>>143
自作のライブラリなら，
hoge_LDFLAGS = -static
をMakefile.amに追加するのかな？
make時なら，./configure --helpして
それなりのオプションがあれば可能だと思う．
0145名無しさん＠お腹いっぱい。
垢版 |
2005/05/07(土) 23:00:52
ありがとうございました
0146名無しさん＠お腹いっぱい。
垢版 |
2005/05/08(日) 14:02:17
共有ライブラリのバージョンが違っても動くプログラムを作る方法を教えて下さい
0147名無しさん＠お腹いっぱい。
垢版 |
2005/05/09(月) 17:10:53
libtoolで困ってます。libtool 1.5->1.5.8でなにか大きな変更があったんでしょうか？
(FreeBSDスレで質問したのですが、だれも答えてくれなかったのでこちらへ来ました。
FreeBSD特有の問題でもなさそうですし…)

(1) FreeBSD-5.2.1, autoconf-2.57, automake-1.7.5_1, libtool-1.5
で開発をしていたのですが、FreeBSD-5.3に移行しようと思い、
(2) FreeBSD-5.3, autoconf-2.57, automake-1.7.5_1, libtool-1.5.8
で環境を整え開発中のソースをビルドしたのですが、 libtoolが作ってくれるはずの共有ライブラリがビルドされません。
＃libtoolのバージョンのみ変わった。

> cp /usr/local/share/aclocal/libtool15.m4 acinclude.m4
> libtoolize15 --force --copy
> aclocal
> autoheader
> automake -a -c --gnu --add-missing --force-missing
んで、
> ./configure
> make

これで環境(1)では共有ライブラリができるのですが、環境(2)ではできなくなってしまいました。
(1)と(2)ではlibtoolizeがコピーするファイルが主に違っているので、libtoolizeが原因かと思い、
環境(2)でソースから libtool-1.5 をインストールしてやると共有ライブラリはビルドできました。
libtool-1.5.16もソースからインストールして同様にビルドすると、今度は共有ライブラリはできませんでした。

configure.ac 内では、AC_PROG_LIBTOOL を指定
Makefile.am では、
lib_LTLIBRARIES = libhoge.la
としています。

libtool-1.5 から libtool-1.5.8 の間にautoconf等の指定の仕方が変わったのでしょうか？
＃なにか指定し忘れてるのだろうか,,,
0148名無しさん＠お腹いっぱい。
垢版 |
2005/05/09(月) 18:05:40
>>147
libtoolのインストール先は他のautoconfやautomakeと同じprefixでしょうか？
確か最近のAutotoolsは同じprefixにしないと問題があるとMLに流れていたと思います。
# ググってもCygwin関係の話しか出てこない (^^;
確認してみてください。

また、(2)の最初の環境ではそのような問題は無いと思うので、
一度、buildディレクトリをクリーンにして試してみてください。
make maintainer-clean だったっけ？
その後で、autoreconf -f -i -Wall
してみてください。
autoconfとautomakeのバージョンによっては、
autoreconfがうまく動作しないかもしれないので、
そのときはちょっと困ります。

config.logあたりに何故できないかの情報があるかもしれないので、
ながめてみてください。
0149147
垢版 |
2005/05/10(火) 00:08:44
>>148
ご丁寧にありがとうございます。

> libtoolのインストール先は他のautoconfやautomakeと同じprefixでしょうか？
これは同じです。すべて prefix は /usr/local としています。

> 一度、buildディレクトリをクリーンにして試してみてください。
> make maintainer-clean だったっけ？
> その後で、autoreconf -f -i -Wall
> してみてください。
これもやってみたのですが、状況は変わりませんでした。

ちなみに autoreconf をすると以下の Warning が出ました。
> autoreconf -f -i -Wall
configure.ac:34: warning: The macro `AC_TRY_LINK' is obsolete.
You should run autoupdate.
　　　　:

これらのWarningは configure.ac の AC_PROG_LIBTOOL でインクルード？される
libtool15.m4 (acinclude.m4 としてconfigure.ac と同じディレクトリにおいてある。) で出ている模様。
でも、Warning だけなのでいけそうな気もするんですが…。

> config.logあたりに何故できないかの情報があるかもしれないので、
> ながめてみてください。
これもみてみたのですが、shared lib 関連はとくに問題なさそうでした。

とりあえず、libtool-1.5 を使っていようと思います。ありがとうございました。
0150名無しさん＠お腹いっぱい。
垢版 |
2005/05/10(火) 00:16:22
>>149
あまりお役に立てなかったようで、、、

後は、ソースからビルドされたようなので、
libtoolのmakeに失敗している可能性もあるので、
libtoolをmakeしたディレクトリでmake checkして、
問題が無いか確認するぐらいかな？
0151名無しさん＠お腹いっぱい。
垢版 |
2005/05/12(木) 00:45:45
↓の書き込みも漏れだったりするけど、多分これだと思う。

540 名前：名無しさん＠お腹いっぱい。：05/02/05 01:29:46
>539
そもそも X 自体入れてないんでどうなんか知らんが。
作らないんじゃなくて、作るけどわざわざ入れないようだ。
devel/libtool15 にわざわざ .la をインストールしないようパッチがされてる。

参考: ttp://www.freebsd.org/cgi/query-pr.cgi?pr=76363

とりあえず x11/libxfce4/Makefile で
-USE_LIBTOOL_VER=15
+USE_INC_LIBTOOL_VER=15
してやれば .la も入るみたいだけど？

0154名無しさん＠お腹いっぱい。
垢版 |
2005/06/23(木) 12:44:19
autopoint で i18n 化した場合って、GPL 互換のライセンスにしないと駄目なの？
intl/ の下に出来るファイルは全部 GPL だよね？

ソフトウェア本体のライセンスは Apache License 2.0 にしたいんだけども。
0155名無しさん＠お腹いっぱい。
垢版 |
2005/06/23(木) 18:12:59
>>154
info gettextのDiscussionsの
* Dependencies over the GPL or LGPL
に[The simplest answer is "normally not".]と書かれている。
一応、読んでみてね。
0156名無しさん＠お腹いっぱい。
垢版 |
2005/06/23(木) 18:32:19
>>155
thx。でも英語が分からん…＿|￣|○

一応読んでみたんだけど、intl/ を含めなければ GPL/LGPL 以外でも
配布できるという解釈で OK?
0158名無しさん＠お腹いっぱい。
垢版 |
2005/06/24(金) 01:56:18
よくわからんが、intlの下ってlibintlに入るものと同じなんでしょ?
削ってしまってlibintlを動的リンクすれば何でもいいんじゃないの?
0159名無しさん＠お腹いっぱい。
垢版 |
2005/10/18(火) 13:52:00
こんにちは。
以下のようなツリーで programA を静的にビルドすると、

　In function '(programAの関数)':
　undefined reference to 'subB1の関数'

と表示されてエラーになります。ディレクトリには subB1.o subB2.o
subA1.o subA2.o programA.o ができてるのですが、
あれこれ調べても原因がわかりません。ヒントでよいですので助言を
お願いします。

/
┃
┣[programB]━┳━[subB1] subB1.c
┃　　　　　　　　 ┃
┃　　　　　　　　 ┃
┃　　　　　　　　 ┗━[subB2] subB2.c
┃
┗[programA]━┳━Makefile.am, configure.in
　　　　　　　　　　┃
　　　　　　　　　　┣━[subA1] subA1.c
　　　　　　　　　　┃
　　　　　　　　　　┣━[subA2] subA2.c
　　　　　　　　　　┃
　　　　　　　　　　┣━[src] programA.c
　　　　　　　　　　┃
　　　　　　　　　　┗ subB1.o subB2.o subA1.o subA2.o programA.o
0160名無しさん＠お腹いっぱい。
垢版 |
2005/10/18(火) 13:56:04
ツリーのみ：
/
┃
┣[programB]━┳━[subB1] subB1.c
┃　　　　　　　　 ┃
┃　　　　　　　　 ┃
┃　　　　　　　　 ┗━[subB2] subB2.c
┃
┗[programA]━┳━Makefile.am, configure.in
　　　　　　　　　　┃
　　　　　　　　　　┣━[subA1] subA1.c
　　　　　　　　　　┃
　　　　　　　　　　┣━[subA2] subA2.c
　　　　　　　　　　┃
　　　　　　　　　　┣━[src] programA.c
　　　　　　　　　　┃
　　　　　　　　　　┗ subB1.o subB2.o subA1.o subA2.o programA.o
0162名無しさん＠お腹いっぱい。
垢版 |
2005/10/18(火) 16:31:26
Makefile.am での”xxx_LIBRARIES =, xxx_SOURCES =”や
configure.in での”AC_CONFIG_FILES()”以外に、
リンク先の指定方法があるのでしょうか？？
なんとなく、各 Makefile.am でリンク先の指定とか
できそうに思うのですが、調べても判りません orz。
0164名無しさん＠お腹いっぱい。
垢版 |
2005/10/21(金) 20:05:57
programA と programB はもともと別の自作ツールで、programB の
一部のソースを programA に流用したもので、Makefile を直接
編集したときはちゃんとコンパイルできるのに、下記のような
Makefile.am configure.in を書いて autoconf automake すると
>>159 のようなエラーが表示されます。なにが悪いのやら…

■ Makefile.am
bin_PROGRAMS = pgA

pgA_SOURCES = \
../programB/subB1/subB1.c \
../programB/subB2/subB2.c \
subA1/subA1.c \
subA2/subA2.c \
src/programA.cc

SUBDIRS = ../programB/subB1 ../program/subB2 subA1 subA2 src
0165名無しさん＠お腹いっぱい。
垢版 |
2005/10/21(金) 20:07:30
■ configure.in
AC_PREREQ(2.59)
AC_INIT(pgA, 0.1.0, BUG-REPORT-ADDRESS)
AC_CONFIG_SRCDIR([src/programA.c])
AC_CONFIG_HEADER([config.h])

AM_INIT_AUTOMAKE(pgA, 0.1.0)

AM_PROG_LIBTOOL
AC_PROG_INSTALL
AC_PROG_LN_S
AC_PROG_MAKE_SET
AC_PROG_RANLIB
AC_PROG_CXX
AC_PROG_CC
AC_PROG_CPP

AC_HEADER_DIRENT
AC_HEADER_STDC
AC_CHECK_HEADERS([stdlib.h string.h])

AC_C_CONST
AC_TYPE_SIZE_T

AC_FUNC_MALLOC
AC_CHECK_FUNCS([memset strchr strstr])

AC_CONFIG_FILES([Makefile])
AC_OUTPUT
0166名無しさん＠お腹いっぱい。
垢版 |
2005/10/22(土) 09:40:24
>>164
共通部分はライブラリにしてしまうのがいいと思うのだが、
後、SOURCESなどでは相対パスではなく、$(top_srcdir)
などを利用するのが、最近の流儀です。
# configureを任意のディレクトリで実行可能にするため。
また、SUBDIRSがサブディレクトリではないのも問題になるかも
しれません。
パッケージ構成を再検討したほうがいいと言うのに私も賛成。
0167名無しさん＠お腹いっぱい。
垢版 |
2005/10/22(土) 20:26:11
自己解決しました。
*.cc ファイルと *.c ファイルが混在してたのに extern "C" {} で囲んで
なかったのが原因のようですた。これで make が通るようになり pgA が
出来上がったのですが、いまいち腑に落ちないです。なんかちょっと
書き換えただけでエラーの表示内容が変化するので何が悪いのか判りにくい…。
まあ、自分が悪いのですが。　お答えいただいた皆さんありがとう
ございました。
0168名無しさん＠お腹いっぱい。
垢版 |
2006/03/27(月) 13:22:52
http://www.ossp.org/pkg/tool/lmtp2nntp/
これなんですけど、LIBS って環境変数を設定してたら、configure に失敗します。
メインの configure で LIBS を自分用にライブラリ追加して設定してるんだけど、
サブの configure にLIBSが環境変数だから引き継がれて悪影響が出てる。

これって、どれ？
1. LIBS を環境変数として指定するのは間違い
2. メインの configure.ac の書き方がまずい
3. autoconf なんてそんなもの
0169名無しさん＠お腹いっぱい。
垢版 |
2006/03/27(月) 21:49:45
>>168
LIBSをunsetしてから
LIBS=hoge ./conifgure
とすると、サブのconfigureに引き継がれないという噂が
利用できるかもしれないが、そうでなければ、
> 1. LIBS を環境変数として指定するのは間違い
かな？
> 3. autoconf なんてそんなもの
これの気もするが、、、
0170名無しさん＠お腹いっぱい。
垢版 |
2006/03/28(火) 17:34:44
> LIBS=hoge ./conifgure
だめみたい。

うーん、configure.ac で
LIBS="$LIBS_EXTRA $LIBS"
するのを止めて、Makefile.in で、
LIBS = @LIBS_EXTRA@ @LIBS@
しないとだめなのかなぁ。
ぶー、ぶさいく。
0171名無しさん＠お腹いっぱい。
垢版 |
2006/03/32(土) 13:15:03
./configure LIBS=hoge
0172名無しさん＠お腹いっぱい。
垢版 |
2006/03/32(土) 15:03:08
ちらしの裏に書いて置くべきことなは、
承知のうえで、あえて、誰かに聞いてもらいたい。

Autoconf,Automake,libtoolのおかげで、コンパイル、インストール
は確かに楽になってると思うんだけど、自分でソース弄りたいなぁ
って思うときに、なんかわけわからなくて。
makefileを自作してたりする。んでそれが面倒なんでソース弄るのも
おっくうになってたり。

みんなはどうしてるの？
0173名無しさん＠お腹いっぱい。
垢版 |
2006/03/32(土) 15:15:07
自分で書くCソースはそもそもそんなに複雑じゃないので、
autoconfを使わなくてもMakefileはOSに依存せず、
異なるOS間でも共通(同一)になることが多い。
なので、Makefileを自分で直接書いてる。
もしくは、もっと簡単なソースだとMakefileすら要らず、
makeのデフォルトルールだけで make hoge 一発でできてしまうことも多いが。
0174名無しさん＠お腹いっぱい。
垢版 |
2006/03/32(土) 17:58:32
>>172
使い方覚えれば自分でソースいじるときもAutotoolsは便利だよ
ソースの依存関係なんてちょっと大きなプロジェクトになると自分で書いてられん

とは言っても最初のmakeにたどり着くまでの作業はちょっと億劫なので
それを自動化したprepare_projectなるスクリプトを書いて使ってる
0175名無しさん＠お腹いっぱい。
垢版 |
2006/04/02(日) 06:43:54
autoconfは便利だしとっつきやすいが、
automakeまで手を伸ばすのはちと面倒なんだよな。

どうせ最初から使う必要なんてないんだから、
必要を感じてきたらそのとき導入すればいいよ。

>> prepare_projectなるスクリプト
MS的にいうとautotools_wizardだね

0178名無しさん＠お腹いっぱい。
垢版 |
2006/04/07(金) 23:19:18
NFS上でaclocal等を実行すると、perlがflock使っているところで
止まるんだけど、これってperlを-Ud_flock付きでコンパイルする
以外に方法はないのでしょうか？ (aclocalは1.9.6)
0179名無しさん＠お腹いっぱい。
垢版 |
2006/06/27(火) 20:01:13
型のサイズが違ったらエラーを出すようにしたいのですけど、
どうしたらいいでしょうか。
configure.inに
AC_CHECK_SIZEOF(int)
AM_CONDITIONAL(CHECK_INT, test "$SIZEOF_INT" = 4)

Makefile.amに
if !CHECK_INT
endif
と書いてみたのですけど、if〜endifの間の書き方が分かりません。
よろしくお願いします。
0180名無しさん＠お腹いっぱい。
垢版 |
2006/07/18(火) 14:34:27
>>179
configureの時点で止めてしまうって話でいいのなら、下の感じだとおもう。試してはいないけど。

AC_CHECK_SIZEOF(int)
if test $SIZEOF_INT != 4; then
AC_MSG_FAILURE([aaaa])
fi
0181179
垢版 |
2006/07/18(火) 21:03:26
>>180
あれからconfigure.inではなくてconfigure.acを使うようにしたのですが、
configure.acの中からではSIZEOF_INTが見えないようです。
生成されたconfigureを見てみると
#define SIZEOF_INT $ac_cv_sizeof_int
という行がありましたので、
AC_CHECK_SIZEOF(int)
if test x$ac_cv_sizeof_int != x"4"; then
AC_MSG_FAILURE([int must be 4 bytes.])
fi
としてみたらうまくいきました。ありがとうございました。
0182名無しさん＠お腹いっぱい。
垢版 |
2006/07/20(木) 20:39:59
autoconf-archive
http://autoconf-archive.cryp.to/macros-by-category.html
を見ていると、マクロの先頭が、AC,ACX,AXなどいくつかありますが、
それぞれどのような違いがあってつけられているのでしょうか。
0183名無しさん＠お腹いっぱい。
垢版 |
2006/10/16(月) 21:53:55
automake-1.10が出たので、autoconf-2.60とともに試しにいれてみた。
ついでにm4-1.4.6にしてみた。古いautoconf関係との解離は大きくなった感じ。
あと、autoconf-2.60のmake checkでエラーになるのだが、
これは、m4-1.4.6のせいで、autoconf-2.60aにするといいらしい。
とりあえず、こんな状況。
0184名無しさん＠お腹いっぱい。
垢版 |
2006/11/24(金) 03:55:10
--with-foo=XXXXの値をMailfileのDEFS変数に反映させてgccのプリプロセッサに反映させたいのですがうまくいきません。
やり方教えて頂けないでしょうか。

AC_ARG_WITH([foo], [ --with-foo (default is /etc/foo)], def_foo=$withval, def_foo=/var/foo)
AC_DEFINE([HAVE_FOO, [def_foo])

としてもMakefileでは

gcc -DHAVE_FOO=def_foo

となってしまいます、、
0188名無しさん＠お腹いっぱい。
垢版 |
2006/12/03(日) 05:15:59
AC_CHECK_LIBに/usr/local/libなどのディレクトリも見てもらうようにするには
どうしたらいいんでしょうか？
0189名無しさん＠お腹いっぱい。
垢版 |
2006/12/08(金) 09:17:54
そもそも、
AC_CHECK_HEADERSがヘッダを探すサーチパス、
AC_CHECK_LIBがライブラリを探すサーチパス、
は、
どこで定義されていて、
どうやったらそこに任意のディレクトリを追加できるのでしょう？
ドキュメントには記述が発見できず...
0190名無しさん＠お腹いっぱい。
垢版 |
2006/12/08(金) 14:19:02
apacheやqmailみたいに１パッケージに複数のアプリケーションが含まれているようなソースツリーの場合にいい感じにconfigureを量産してくれるようなautotoolsが欲しい。
0192名無しさん＠お腹いっぱい。
垢版 |
2006/12/09(土) 22:48:56
>>191
ありがとうございます。
/usr/share/autoconf/autoheader.m4f にそれらしき部分を見つけました。

/usr/share を変更できない権限で configure 実行時にサーチパスを追加
する方法を探しています。
環境変数INCLUDEにセットしてみたり、
./configure INCLUDE=hoge
とかやってみているのですが、うまくいかずです。
0193名無しさん＠お腹いっぱい。
垢版 |
2006/12/13(水) 15:01:54
./src
　main.c
　./others
　　hoo.h
という階層があって、main.cからhoo.hを読み込んでいるのですが、Makefile.am
はどのように書けばいいのでしょうか？
0195名無しさん＠お腹いっぱい。
垢版 |
2006/12/14(木) 04:27:56
>>192
環境変数で解決しました。
AC_CHECK_HEADERS は CPPFLAGS=-I<include_dir>、
AC_CHECK_LIB は LIBS=-L<lib_dir>
で設定したディレクトリを探してくれるようです。
0196手元にある本から・・・
垢版 |
2006/12/16(土) 18:51:20
>193
GNU Autoconf/Automake/Libtool
ttp://www.amazon.co.jp/Autoconf-Automake-Libtool-Gary-Vaughan/dp/4274064115/

P48 6.5:よくある質問　から引用
ライブラリのソースが複数のサブディレクトリにあるとき、どうmakeしたらよいでしょうか？

ライブラリではほとんどの場合、libtoolコンビニエンスライブラリを使うことで簡単に解決できます。
しかし、プログラムについては簡単な解決策がなく、パッケージの構造の変更を選ぶ人が少なく有りません。
Automakeの次期メジャーリリースでは、この問題に進展があるはずです。


最新verならできるのかな？この本が翻訳された段階(平成13年)ではまだ無理っぽいみたいだし
0197名無しさん＠お腹いっぱい。
垢版 |
2006/12/16(土) 19:59:25
>>196
ありがとうございます

どうにも良く分からないので
./src
　main.c
　./others
　　hoo.h
　　hoo.cpp
を、libothers.aとライブラリにして、./srcでリンクさせてます。（リンクが成功しないんですがこれは別問題かと）
うーむ、実際にautotoolsで作ってる人はどうしてるんだろうか
0200名無しさん＠お腹いっぱい。
垢版 |
2006/12/17(日) 09:22:03
>>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], [nanasi@example.com])
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
0201198
垢版 |
2006/12/17(日) 18:48:32
>>199
具体的もなにもmain.cのあるディレクトリのMakefile.amで
hoge_SOURCES=main.c others/hoo.h others/hoo.cpp
するだけだよ
othersにあるファイルも同じように扱えるようになったみたいなので
わざわざライブラリにまとめる必要はない
0202名無しさん＠お腹いっぱい。
垢版 |
2006/12/17(日) 23:34:00
>>200 >>201
ありがとうございます。

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

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

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

判断できない場合は、とりあえずインストールするのが無難です。
# libhoo.laはデバッグ時に必要です。
0205名無しさん＠お腹いっぱい。
垢版 |
2006/12/18(月) 23:43:10
>>204
> *.laって何するものなの?
$ libtool gdb hogehoge
ってやるとき、参照するライブラリが書かれているテキストファイルだと
思っているのですが、、、
識者の方ツッコミよろ。
0206名無しさん＠お腹いっぱい。
垢版 |
2006/12/24(日) 20:13:53
noinst_ だったらコンビニエンスライブラリになるから、実行形式の方には最終的に静的リンクされて .la なんか不要になるはず。
0207名無しさん＠お腹いっぱい。
垢版 |
2007/06/23(土) 21:05:43
AC_CHECK_HEADERなどで宣言されるHAVE_*の先頭に識別子をつけることはできる？
#define HOGE_HAVE_MEMORY_H
となるような。
hoge_config.hをライブラリのヘッダーから読み込もうと思っているのですが
ライブラリを使う側にHAVE_*が影響してしまうので
ライブラリのコンパイル後に消すか、名前を変えるかしたい。
しかし、ライブラリヘッダーが提供する構造体要素の型をHAVE_*を見て切り替えたいので
単純にconfigヘッダーをインストールしないというわけにもいかず。
0208名無しさん＠お腹いっぱい。
垢版 |
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_* の状態が違っているなら正常動作しなくても当然なんじゃない？
0210名無しさん＠お腹いっぱい。
垢版 |
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の意味が無いというか。
普通どうやるんでしょ？
0211名無しさん＠お腹いっぱい。
垢版 |
2007/06/24(日) 23:10:23
>>208
>ライブラリ作成環境と実行環境で HAVE_* の状態が違っているなら正常動作しなくても当然なんじゃない？
動作というより、他のプログラムが使う可能性のあるマクロ名を汚染してしまうのが嫌。
Cだから仕方が無いといえばそうだけど、せめてHOGE_*にしてあげたい。
0213名無しさん＠お腹いっぱい。
垢版 |
2007/06/25(月) 17:54:39
>>210
ライブラリのヘッダファイルであるかどうかわからないtypedefをさらにtypedefって
あまり見ないような。大抵自分で型を判断してやってないか。
0214名無しさん＠お腹いっぱい。
垢版 |
2007/06/25(月) 23:28:01
>>213
自分で判断というのはhogeが定義してあるのでOSはhageだとかCPUはfooだとかで
つまり4バイト数値型はhoge_intとかですか。
それがconfigureでやることではないのですか？
0216名無しさん＠お腹いっぱい。
垢版 |
2007/07/07(土) 22:49:39
>215
ライブラリを使う側でいちいちどのマクロを定義してやる必要があるかを考えるのが面倒くさい…と思ったんだけど、
そのライブラリ用に Autoconf マクロを作ってしまうというのでその点は解決するか。
その上で、ヘッダ側では

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

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

まあ、hoge_config.h.inから作るってのも解決方法の一つかもしれないけど、
どっちが良いかはよく分からないです。
0218名無しさん＠お腹いっぱい。
垢版 |
2007/07/23(月) 03:24:18
CFLAGSとCPPFLAGSの違いがよくわかりません
Cプリプロセッサフラグってどういうことでしょうか？
-I/fuga/fuge/
をコンパイル時に指定したい場合、
CFLAGS=-I/fuga/fuge/
だと追加されなくて
CPPFLAGSに指定すると追加されてました。
ちなみにC++のファイルです。
0221名無しさん＠お腹いっぱい。
垢版 |
2007/07/23(月) 21:04:35
まず問いたい。
おまえはそれを見て、それが正解だと推測したわけだよな？
公式のマニュアルではなく、なぜそんな下らんもので推測したんだ？
0222名無しさん＠お腹いっぱい。
垢版 |
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を処理するのが何か分かれば
多分理解できると思う。
0223名無しさん＠お腹いっぱい。
垢版 |
2007/07/23(月) 23:56:05
ありがとうございます。
プリプロセッサの処理にコマンド指定できるんですね・・・知らんかったです。
C++でのオプションはCXXFLAGSで指定します。
サンクスでした
0224名無しさん＠お腹いっぱい。
垢版 |
2007/07/24(火) 23:43:52
まず問いたい。
>という自分の推測が間違っているということを疑わないのか。
という発言が出てくるのか。
CPPFLAGSがC++用フラグだとでも自分の推測で発言したのか？w
0226名無しさん＠お腹いっぱい。
垢版 |
2007/11/29(木) 08:39:52
できるかどうかわからないけど、なぜそういうことをしたいのか
の目的がわかれば、別の解決法が出てくるかもね。
0227名無しさん＠お腹いっぱい。
垢版 |
2007/11/29(木) 11:49:47
自分のホームディレクトリにソースがあったとしても、
/tmp/でmakeしたいんです。

/home/my/src/"ここにソースがある"
けど、makeを叩くことで、
/tmp/でビルドさせたいんです。
0228名無しさん＠お腹いっぱい。
垢版 |
2007/11/29(木) 19:43:54
>>227
> 自分のホームディレクトリにソースがあったとしても、
> /tmp/でmakeしたいんです。

/tmp で/home/my/src/configure
すれば、/tmp以下にMakefileができると思うけど。
そういう話ではない？
0229名無しさん＠お腹いっぱい。
垢版 |
2007/11/29(木) 23:14:50
Makefileの中身が相対パスで書かれてるみたいなので、
/tmpでmakeをしてもエラーが出るんですよね・・・
やっぱり、ソースツリーを全部/tmpにコピーってconfigure,makeした方が
早いですかね？
0232名無しさん＠お腹いっぱい。
垢版 |
2007/12/01(土) 09:41:28
>>231
srcdir や top_srcdir への相対パスなら大丈夫だけど、
# 絶対パスならabsを付ける
カレントディレクトリからのパスになってるんじゃない？
0233名無しさん＠お腹いっぱい。
垢版 |
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

を見に行ってしまいエラーになってしまいます。
回避する方法ってありますか？
新着レスの表示
レスを投稿する

ニューススポーツなんでも実況