1名無しさん＠お腹いっぱい。NGNG
奥深さの前に使い方がさっぱり分からん。教えて下さい。
関連サイトは>>2 3名無しさん＠お腹いっぱい。NGNG
もの凄い勢いで終了したスレはここですか？
4名無しさん＠お腹いっぱい。NGNG
http://www.ainet.or.jp/~inoue/gnu/whatis.html
> なぜ使うのか
> もちろん、表の理由は、移植性の高いソフトウェアを作ることにありますが、
> 裏の理由として、GNUへの忠誠を示すことができる点があります。
……(´д`；)
53NGNG
本当に終了してる(^_^;)ﾏｧｳﾞｻｹﾞ
6名無しさん＠お腹いっぱい。NGNG
configureスクリプトよく見たらsockaddr.sa_lenがあるかどうかとか
チェックしてくれているのね。少し驚いたので、あげ。
7デフォルトの名無しさんNGNG
>4
RMSの言う自由ってさ、ブッシュの言うそれと似てる気がする。
ま、彼も所詮「アメリカ」人ってことだーね。
8名無しさん＠ＸＥｍａｃｓNGNG
ウゼえ消えろ
∧＿∧ ＿ ＿ .' ， ．. .∧＿∧
（ ´_ゝ`） _ .- ― .＝￣ ￣`:, .∴ ' （ >>1 ）
／ ''￣ ＿＿――＝', ・,‘ ｒ⌒> _／ ／
/ /＼ /￣＼-― ￣￣ ￣"'" . ’ | ｙ'⌒ ⌒i
＿|￣￣ ＼ / ヽ ＼＿ | ／ ノ ｜
＼￣￣￣￣￣￣ ＼＿_） , ー' ／´ヾ_ﾉ
||＼ ＼ ／ , ノ
||＼||￣￣￣￣￣￣￣||￣ ／ ／ ／
|| ||￣￣￣￣￣￣￣|| ／ ／ ,'
|| || || ／ ／| |
!､＿／ / 〉
∧＿∧ 死ね
_（ ´_ゝ｀）
／ ） ＿ _
/ ,ｲ 、 ﾉ/ ∧ ∧―＝￣ ｀ヽ, ＿
/ / | （ 〈 ∵. ・（ 〈＿_ > ゛ 、＿―
｜ ! ヽ ｰ＝-￣￣＝_、 （／ , ´ノ
｜ | ｀iー＿＿＝―＿ ;, ／ ／ ／ ←>>1
!、ﾘ -=＿二＿＿￣_=;, ／ ／ ,'
/ / ／ ／| |
／ / !､＿／ / 〉
／ ＿/ |_／
ヽ､＿ヽ
正 直 逝 っ て >>1 は ア ホ
_,-'' ） 。ﾟ･ ｡ 。
∧ ∧ , -' （.__,-'' , , , 。゜
, - ´_ゝ｀）_ .,-'~ ,- ' / / ｉ～ｉ /, 。
/ ）ヽ(w i .,-'~ ,-'~ // , /// ～ //,
.,/ / ヽヽヽ ,-/'~ ,ノ / ////＠ ＠// '/
/ ^)'死 _ ｌ ゝ _)-'~ ,-'~ //, ' ⌒/∨￣∨ ⌒ヽ
/ /' ヽ ^￣ ,-'~ / / >>1 ヽ ﾟ ･
（ｉｉｉｉﾘ∫ ヽ .／ (⌒`～～' ／i ノ 愛 ノ＼ ヽ
ヽ─|～' ノ／ ﾞ～～～～ | ./ `- '
|| ||l､_ / ,,, | ／ ﾟ 。
|.| ＿|.|＿,,,| | __-'',,-~ / /
.|.| ニ─､─''''| | =-''' / ､ ヽ
.|.| |.| .| | | l l
|.| |.| .| '､ _ ＿.| / ノ
.|.| ,,=＝ ＝=.| l .|.| ,_,,-'',,,-| / | /
|.| ||＿ﾉﾉ | | i､`''',,-'''' | / .| .|
.|.ﾚ `-- ' | | ￣ ｜ .ﾉ | ）
,- | | ..... ｜ .| ｜｜
`ヽ ）;;;::::::::''''' | ｜ | .|
ﾞ - ''''''' ,- ､| | ,,,,,;;;;;;;;と__）''
＼_＿);;;;;;;''''''
9名無しさん＠お腹いっぱい。NGNG
特定のライブラリがユーザによってインストールされているかを
autoconf で調べるのって邪道だと思わない?
10名無しさん＠お腹いっぱい。NGNG
>>9 ライブラリ作者に.m4ファイルを書けってこと？
そこまでFSFに魂を売り渡したくない人達はどうするよ。
たとえば、X関係とか。
11名無しさん＠お腹いっぱい。NGNG
Imake最強
12名無しさん＠お腹いっぱい。NGNG
おめーらんなこというならgcc使うなよ
14名無しさん＠お腹いっぱい。NGNG
なんかこの板最近殺伐としてきたな。喜ぶべきことかどうなんだろうか･･･
15名無しさん＠お腹いっぱい。NGNG
>11
いつのまにcross buildの機能が付いたね。FreeBSD的には有難い。
しかし、そんなこと知らずに偽cpp作ってゴリゴリhost.defとか書た
苦労はいったい・・・
16名無しさん＠お腹いっぱい。NGNG
autoconf、automakeのスレ、荒れてる。
もったいないよ、盛り上げようよ。
18名無しさん＠お腹いっぱい。NGNG
configure.inを書かずにGPLで配布することは恥かしいことなんですか？（ｗ
19名無しさん＠お腹いっぱい。NGNG
>>18 configure.in
configure.acを利用しない方が恥ずかしい罠。
20名無しさん＠お腹いっぱい。NGNG
どーでもいいけど板違いな気がするんですが
219NGNG
>>10
autoconf は OS 間の非互換性を補う使い方に留めてほしい。
自分がリンクしたいライブラリが無かった時、勝手に WITHOUT_LIBHOGE
みたいなオプションを付けてそれ抜きでコンパイルするのは嬉しくない。
そのライブラリを使うか使わないかはユーザが決める事柄なんだから、
--with-libhoge とも --withoug-libhoge とも指定してないのに、勝手に
WITHOUT_HOGE とかして欲しくない。
黙ってコンパイルして、黙ってリンカエラーを出してくれればそれでいい。
事前に親切に「libhoge ねえぞ、入れろやｺﾞﾙｧ」と言ってくれれば便利だが、
そこまでは求めない。
あと、OS 標準じゃない物を探すんだったら /usr/lib と /usr/include
以外の場所も適宜探してくれないと不便だと思う。何でも /usr 直下に
突っ込むことを暗黙の前提としているのではないか。 2210NGNG
了解。勘違いしていた。
>>21
> 自分がリンクしたいライブラリが無かった時、勝手に WITHOUT_LIBHOGE
> みたいなオプションを付けてそれ抜きでコンパイルするのは嬉しくない。
これは同感です。
# というより、Autoconfの使い方が悪い。
> 黙ってコンパイルして、黙ってリンカエラーを出してくれればそれでいい。
これやっちゃうと、バグの報告が大量に発生すると思うので、マトモなパッ
ケージなら、
> 事前に親切に「libhoge ねえぞ、入れろやｺﾞﾙｧ」
と言ってくれると思うんですがどうでしょう。
# マトモの定義の話は無しね。
多分、Makefileを適切に書くのが面倒だから「Automake Autoconfでパッケー
ジ作りました」ってのが多いんだと思う。AC_CHECK_XXXの引数できちんとエラー
処理すれば大丈夫でしょ。
> あと、OS 標準じゃない物を探すんだったら /usr/lib と /usr/include
> 以外の場所も適宜探してくれないと不便だと思う。
ライブラリについてはリンクを実際に行なって調査するので、ユーザが環境変
数を設定することで何とかなりますし、ヘッダの方もコンパイル可能かどうか
を調査するので同じことではないでしょうか？
ま、言いたいのは、道具はいいけど使い方は人それぞれってことです。 24名無しさん＠お腹いっぱい。 NGNG
関係ないんだけど、いいですか？
UNIXの人はWindowsでプログラミングするときは
nmakeとcygwin(gmake)のどっち使ってますか？
nmake使いづらいです。。
25名無しさん＠お腹いっぱい。NGNG
>>24
nmakeってことはVC++？
だったらmsdev使うけど。 27名無しさん＠お腹いっぱい。NGNG
>26
バカヤロウ。ここはUNIX板。
Windowsはcygwinを入れて使うもんだろ。
コンパイラまでgnuを使うわけにはいかないことも
あるが、それ以外は当然全てgnu！
28名無しさん＠お腹いっぱい。NGNG
Automake 1.6.2 released
sageですが ;-)
29名無しさん＠お腹いっぱい。NGNG
JavaプログラムをAutoconf/Automakeに対応させるにはどうしたらいいのかな?
最低限 make と make install と make dist を使えるようにしたいのだけど。
で、
--- Makefile.am ---
bin_PROGRAMS = hello.jar
hello_jar_SOURCES = Main.java
-- configure.in --
AC_INIT(Main.java)
AM_INIT_AUTOMAKE(hello, 1.0.0)
AC_ARG_PROGRAM
AC_PROG_INSTALL
AC_PROG_CC
AC_OUTPUT(Makefile)
とかやってみたけど当前のように正しいMakefileは出来ないし。
30名無しさん＠お腹いっぱい。NGNG
>>29
> JavaプログラムをAutoconf/Automakeに対応させるにはどうしたらいいのかな?
> 最低限 make と make install と make dist を使えるようにしたいのだけど。
Automake-1.6.2とAutoconf-2.53だと、gcjを利用したコンパイルができるみたい。
でも、うちはJAVAの環境が無いから試せないです。
automakeのinfoの、ノード"Java Support"を参照してみてください。 3129NGNG
>>30
gcjを入れてみたけどlibgcj.specが????とか出て動かない。かなり険しそう(w
とりあえずAutomake-1.4のinfoで'_JAVA'がどうのこうのって記述を見つけたので、
javacで動くように試してみます。 32名無しさん＠お腹いっぱい。NGNG
>>31
> とりあえずAutomake-1.4のinfoで'_JAVA'がどうのこうのって記述を見つけたので、
> javacで動くように試してみます。
1.4のやつって、javacでのコンパイルのみのサポートだったと思います。
# 記憶が曖昧ですみません。
info にもありますけど、.javaと.classのサフィックスルールを自動的に作れ
ない(ファイルの中からクラス名を調査する必要がある)のでそのような仕様だっ
たと思います。だからmakeはできてもmake installは難しいと思います。
# でもうまくいったら教えてください。
33名無しさん＠お腹いっぱい。NGNG
Autoconf-2.53b 開発版リリース（結構前だけど）
どーでもいいけど、autoconf-mode.elとかautotest-mode.elとかあるのね。
色が変わるだけみたいだけど。
34名無しさん＠お腹いっぱい。NGNG
知らない間にac-2.54 am-1.7になってたのね。
amのdrilistって便利そうなんだけど使っている人いる？
--confiugre=$HOMEしている人ぐらいなのかな。
# ム板のmmmpスレのほうが活発かな？
38名無しさん＠お腹いっぱい。NGNG
autoconfは便利なんだけど、これに対応するようになってから
ソースの見通しが悪くなった。
39名無しさん＠お腹いっぱい。NGNG
前は環境依存部分を別関数にしたりしてたけど、最近は面倒だからやめた。
確かに見通しは悪くなった。GNUのソースも見るのが辛くなってきた。
# なんか愚痴ばっかりだな。
40名無しさん＠お腹いっぱい。NGNG
この前からCommon Lispで書かれた数式処理ソフトウェアの構成を
追ってみようとしてるんだけど、main関数のないLispソースを
autotoolsでビルドする構成になってるので、さっぱり分からない。
Autotoolsを使うときには、想定しているコンパイラ・ライブラリの組み合わせと
依存関係を簡単にドキュメント化してくれないと困ってしまう。
逆に移植などがし辛くなってしまうよ。
41名無しさん＠お腹いっぱい。NGNG
>>40
とりあえずconfigureしてlog見るんじゃだめなの？
Common Lisp知らないからいい加減なこといっているけど。 42名無しさん＠お腹いっぱい。NGNG
コンパイル型言語じゃないからね、Lispの「メモリダンプ」とかって独特なんです。
で、どんなコマンドが実行されてるんだか
（というか、山ほど実行されてるコマンドのうちどれが重要なのか）分からない。
43名無しさん＠お腹いっぱい。NGNG
いろいろ大変なんですね。LispはEmacsのしか知らないし、
AM_PATH_LISPDIR使っているものしか見たこと無いんで、
役に立たずですまんです。
# autoconfにもLispファイルがあります。
44名無しさん＠お腹いっぱい。NGNG
Autoconf,Automake,Libtoolを解説してる本って少ないながらも一応あるようですけど，
どんなもんでしょう？いい本なのでしょうか？
45名無しさん＠お腹いっぱい。NGNG
多分あの本だと思いますがいい本です。ただし、最新のAutoconf、Automakeを
利用するとちょっと戸惑うかもしれません。セレンディップのGNOMEプログラ
ミングという本にもこれらの解説があります。
46名無しさん＠お腹いっぱい。NGNG
オーム社の本の事ですか？
47名無しさん＠お腹いっぱい。NGNG
>>46 そうだと思う。
んでも、少々高いから、漏れは立ち読みで逝こうかとｗ 48名無しさん＠お腹いっぱい。NGNG
やっぱりm4マクロの勉強からかな
50名無しさん＠お腹いっぱい。NGNG
２割、３割はあたりまえ。
53名無しさん＠お腹いっぱい。NGNG
CVSにconfigureまで突っ込んでるプロジェクトもたまに
ありますが、ふつうはどこまで含めるものなんですか。
54名無しさん＠お腹いっぱい。NGNG
FreeBSD PORTS なんかだと、
autoconf{,213,254,257} や automake{,14,16,17} や libtool{,13,14} のように、
古いバージョンも後生大事に用意されていますよね。
これは何故なんでしょうか？
何か後方互換性に大きな問題でもあるのでしょうか？
56名無しさん＠お腹いっぱい。NGNG
>>55
なるほど。
そうだとして、この場合はそれぞれこのバージョンを使えば良い/いけない、
といった判断は一般にどのような基準に基づいて行えば良いのでしょうか？ 57名無しさん＠お腹いっぱい。NGNG
>56
違うバージョンを使うと動かないので悩む必要はありません。
58名無しさん＠お腹いっぱい。NGNG
>>57
う～ん、やっぱり良くわからないです。
とどのつまり、知りたいのは、
PORTS や package のような仕組みの無い OS に automake や autoconf を入れる場合、
とりあえずそれぞれ最新のバージョンのを入れておけば問題ないものなんでしょうか？
それとも、古いバージョンのも入れておいた方が良いのでしょうか？ 59名無しさん＠お腹いっぱい。NGNG
>>53
configure.acまでと言いたいが、今のAutotoolsのバージョン間の互換性から、
configureまで入れておいたほうが無難。誰でもcheckoutできるプロジェクト
なら、「autoconfを実行するとエラーが出ます」というレポートが大量発生す
る可能性が高い。しかし、confugure.acやMakefile.amを書き換えると同じ状
況になるんだよね。
AM_INIT_AUTOMAKE([1.7])とかAC_PREREQ(2.57)とか書けばいいのかな？ 60名無しさん＠お腹いっぱい。NGNG
>>58
Autotoolsを自分のプロジェクトで使うのなら、最新を入れて問題ないです。
他のプロジェクトに参加するなら、そのプロジェクトが推奨するバージョンが
あります。適当にソース持ってきて自分でソースなどを修正する時は、そのソー
スを書いた人が使っているものと同じバージョンがないとうまく動かないこと
もあります。更に、これらのツールは同じprefixにインストールしないとうま
く動かない場合が多いです。
私は、$HOME以下のディレクトリにいろんなバージョンが入っているのですが、
libtoolだけはいい方法が見つからないです。 61>>53NGNG
>>59
さんくす。内輪のプロジェクトなんでconfigure.acまでにしときます。
すでにautotoolsの互換性に悩んでるんだけど、最新版推奨で行くことにします。
configureはtarballに入れればいいし。 62名無しさん＠お腹いっぱい。NGNG
>>60
どうもです。
私はとくに他人のプロジェクトに参加したりということもなさそうですので、
最新のを入れて問題なさそうですね。 63名無しさん＠お腹いっぱい。NGNG
とあるソフトの configure.in、
AC_SEARCH_LIBS(tputs, ncurses termcap, HAVE_TERMCAPとdefine, ダメです)
みたいなライブラリチェックしかなくてSolaris8上でのconfigureが不能です。
対症療法よりもその辺全面的に書き換えようと思うんで、
configure.in での termcap, curses, ncursesのチェックのお手本になるソフト探してます。
readlineをリンクすることも可能で、Solarisでconfigure;make 可能なソフト、
なんかないでしょうか？gdb?
64名無しさん＠お腹いっぱい。NGNG
>>63
GNU texinfoが、tercap、ncurses、readlineなどを使ってるみたいです。
infoコマンドのソースはgdbより少ないかな？ 6563NGNG
>>64 情報ありがとうございます。当たってみます。 66名無しさん＠お腹いっぱい。NGNG
済みません、ちょとお邪魔させてください。
事情により初めてautoconf/automake使い始めたとこなんですが、
unyalib--------------------subDirA
ソ ースいくつか | ソースいくつか
|
|
|-----subDirB
ソースいくつか
という具合に、ライブラリソースのディレクトリ直下に、ソースが有り、
なおかつ、そのライブラリの一部になっているサブディレクトリにも
ライブラリのソースが有り、という状況ですが、解説ページとかを参考に、
67名無しさん＠お腹いっぱい。NGNG
解説ページとかを参考にして、
-- unyalibのMakefile.am ------
SUBDIRS = subDirA subDirB
noinst_LIBRARIES = libunyalib.a
libunyalib_a_SOURCES = unya.c honya.c
-- subDirAのMakefile.am ----
noinst_LIBRARIES _ libunyalib.a
libunyalib_a_SOURCES =
libunyalib_a_LIBADD = unya_a.c honya_a.c
-- subDirBもsubDirAと同じように"LIBADD"を使用 ----
とかいうように、書いてautomakeを動かしてみました。
でも、結果としてのMakefile.inは、どのディレクトリのものでも
unyalib.a: $(unyalib_a_OBJECTS) $(unyalib_a_DEPENDENCIES)
-rm -f unyalib.a
$(AR) cru unyalib.a $(unyalib_a_OBJECTS) $(unyalib_a_LIBADD)
$(RANLIB) unyalib.a
と、ar の前に必ずrm が実行されて、一つのライブラリに合体してくれない状態です。
サブディレクトリの方ではrmの実行が挟まれず、一つのライブラリにさせる技は無いでしょうか。
69名無しさん＠お腹いっぱい。NGNG
そりゃサブディレクトリでやったらそれぞれ別物だし、
一つのライブラリになるわけはない罠。
7067NGNG
えーと、やっぱ駄目ですか。
automakeって、一つの結果(実行形式でもライブラリでも)を作るためのソースは、
一つのディレクトリに集まっているというのしか想定していないということでしょうか。
71名無しさん＠お腹いっぱい。NGNG
SUBDIRS使わずに、SOURCESで相対パス指定でできなかったっけ？
$(topsrcdir)とかで指定するんだったかも。
1.4頃の記憶なんで違うかもしれん。
どっちかというとlibtoolsの話かもしれんけどね。
7267NGNG
やってみました。
SUBDIRS無し、
libunyalib_a_SOURCES = unya.c honya.c subDirA/unya_a.c subDirA/honya_a.c
とかしてみると、
subDirA下のソースに対するオブジェクトがunyalib(ライブラリソースツリーの根っこ)下に
作成されるけど、ライブラリのためのオブジェクトはサブディレクトリから取ってこようとする
Makefileが出来ちゃいまひた。
で、もう、最初のMakefile.inはautomakeで作るけど、
それを手で修正して以後automakeは使わないという決定が
本日なされちゃって、この件は棚上げとあいなりました。
ありがとうございました。
73名無しさん＠お腹いっぱい。NGNG
>>1
使いにくいのを奥深さと勘違いしてるだけだろ。 74>>53NGNG
>>73
奥が深くて使いづらいと申し上げているのです。 77名無しさん＠お腹いっぱい。NGNG
makeができない。
78名無しさん＠お腹いっぱい。NGNG
automakeで作ったMakefileってgmakeに依存する?
79名無しさん＠お腹いっぱい。NGNG
>>78
基本的には依存しない。Makefile.amの内容によっては依存する。 8481NGNG
>>67
ん?
-- unyalibのMakefile.am ------
SUBDIRS = subDirA subDirB
noinst_LIBRARIES = libunyalib.a
libunyalib_a_SOURCES = unya.c honya.c
libunyalib_a_LIBADD = libsubdir_a.a ...
-- subDirAのMakefile.am ----
noinst_LIBRARIES = libsubdir_a.a
libsubdir_a_a_SOURCES = unya_a.c honya_a.c
でいいんじゃないの? 手元で試してないから嘘言ってるかもしれないけど。 8581=84NGNG
間違えた。
libunyalib_a_LIBADD = libsubdir_a.a ...
は
libunyalib_a_LIBADD = subdirA/libsubdir_a.a ...
ね。
86名無しさん＠お腹いっぱい。NGNG
auto* っつーもんは、backward compatibility を放棄した糞ということでよろしいか？
87名無しさん＠お腹いっぱい。NGNG
Autotools で生成したものの再配布は GNU ライセンスに準じるの？
88名無しさん＠お腹いっぱい。NGNG
>>87
準じないけど、Automakeで配布されるファイルには
いろんなライセンスがあっはず。
バイナリ配るんなら問題無かったと思う。
>>86
糞かどうかは知らんが、同意したい気分だね。 89名無しさん＠お腹いっぱい。NGNG
まあ、こいつの登場で便利になっている事実は否定できないので、
backward compatibility を確保して欲しかったということだけかな。
90名無しさん＠お腹いっぱい。NGNG
backward compatibilityを維持したらどんな事態になるか分るだろ。
91名無しさん＠お腹いっぱい。NGNG
∧＿∧∩ ／￣￣￣￣￣￣￣￣￣￣￣
（ ´∀｀）/＜ 先生！わかりません！！
＿ / / / ＼＿＿＿＿＿＿＿＿＿＿＿
＼⊂ノ￣￣￣￣＼
||＼ ＼
||＼||￣￣￣￣￣||
|| ||￣￣￣￣￣||
.|| ||
93名無しさん＠お腹いっぱい。NGNG
Automake-1.7.7のconfigureがAutoconf-2.57だと通らず、
Autoconf-2.54だと通る。
config.logは以下の通り（一部抜粋Autoconf-2.57のとき）。
configure:1724: cd conftest && eval autoconf -o /dev/null conftest.ac
autom4te: no such file or directory: m4sugar/m4sugar.m4
configure:1727: $? = 1
configure:1731: error: Autoconf 2.54 or better is required.
Is it installed? Is it in your PATH? (try running `autoconf --version')
Is it working? See also config.log for error messages before this one.
なんか情報ありませんか？
96名無しさん＠お腹いっぱい。NGNG
>>95
distclean できる *はず* なので、正直どうでもいい。 97名無しさん＠お腹いっぱい。NGNG
確かにdistcleanできる *はず* ですね。
個人で開発に利用するときは、cleanすら使うことが少ないから、
良く理解していなかった。
98名無しさん＠お腹いっぱい。NGNG
./configureしたときのデフォルトの$prefixが/usr/localなのが不便なので、configure.ac
やMakefile.acの中で--prefix=/usrの指定をできないでしょうか？
99名無しさん＠お腹いっぱい。NGNG
>>98
AC_PREFIX_DEFAULTを使う。詳細はinfo Autoconfとかして見るべし。
しかし、デフォルトのprefixを/usrにするのはあまり行儀の良いもの
ではないと思うが。
100名無しさん＠お腹いっぱい。NGNG
Makefile.ac
101名無しさん＠お腹いっぱい。NGNG
>>100
ああ、Makefile.amの間違いだよな。 102名無しさん＠お腹いっぱい。NGNG
>>99
ありがとうございます。
ところでprefixを/usrにするとどういうデメリットがあるのでしょうか？ 103名無しさん＠お腹いっぱい。NGNG
>>101
ごめんなさい。その通りMakefile.amの間違いです。 104名無しさん＠お腹いっぱい。NGNG
>>102
/usr の下はユーザにとって最低限必要なものが入ってるので、そういう重要なファイルと
ユーザがインストールしたものの中で名前が衝突し、置き変えられたりするとまずい。
/usr/bin/cc が上書きされたらどうなるかは簡単に想像できるとおもう。
Linux とかはパッケージで入れるものは全部 /usr に入れるのが多い
(衝突が検知できるから問題にならない)けど、 *BSD は別にディレクトリを掘って
そこに入れてる。/usr の下は一切いじらないポリシーを厳格にまもってるんだとおもう。 105名無しさん＠お腹いっぱい。NGNG
OSの一部として配布されるもの以外は/usrに入れないのが当り前です。
システム上重要というだけでなく、そのOSを使っている人の間で構成が
一致しているからでもある。
Linuxはその意味ではいまだ寄せ集めの域を出ていないのかな?
もしだとすると>>102のようになんでも/usrに叩き込むということになっちゃっ
うのも納得できる。
>>104の前半にあるような問題は既にLinuxユーザでは起きているみたいだし。
106名無しさん＠お腹いっぱい。NGNG
寄せ集めっつーか、大多数のLinuxディストリにはbase systemと
いう概念が無いからなぁ。「無けりゃインストールしろ」「インストール
したらそれもbase systemの一部だ」みたいなノリなんだろうね。
107ヽ(´ー`)ノNGNG
>>105
Linux だと FHS(File Hierarcy Standard だっけな)って標準があるよ。
最近のメジャーなディストリは準拠してる(Debian,SuSE,Fedora,Turbo...)。
特別な理由もなく --prefix=/usr するのは、お行儀の悪い鯖管だけだね。
> Linuxはその意味ではいまだ寄せ集めの域を出ていないのかな?
これは、もはや昔話だよもん。
108名無しさん＠お腹いっぱい。NGNG
一度rpmにするものは/usrにしてる。
109名無しさん＠お腹いっぱい。NGNG
libtool.m4に入ってるチェックで、Fortranコンパイラを勝手に探したり、
maximum length of command line argumentsとか言ってCPU食うのを
やめさせたいんですけど。そういうACマクロはないんでしょうか？
110名無しさん＠お腹いっぱい。NGNG
>>109
「勝手」にチェックする m4 なんてない。
configure.{ac,in} から呼び出してる(つまり必要である)から行われてるチェック。
気に入らなきゃチェックしてるところを外せ。
# それでまともにコンパイルできるとは思えんが。
111名無しさん＠お腹いっぱい。NGNG
えーと言い方が悪かったですが、AC_PROG_LIBTOOLマクロを使うと
ほとんどのパッケージには不要なはずのチェックが盛りだくさんに
はいるわけです。
とりあえず全部チェックしておけばどんな場合にも対応できるってこと
なんでしょうが、不要なものをdisableにするくらいできてもいいよねえ、
そういうマクロあります？って話です。
libtool.m4が洗練されてないと言えばそれまでですがね。
112名無しさん＠お腹いっぱい。NGNG
古いlibtool使うしかないのでは？
113名無しさん＠お腹いっぱい。NGNG
>>109
AC_LIBTOOL_SETUPのAC_LIBTOOL_SYS_MAX_CMD_LENをコメントアウトするとか、
自分でlibtool.m4を書き換えちゃえば？
うまく動く保証は無いし、libtool使う意味も減ると思うけど。
移植性考えないんならlibtool使わなくてもいいんじゃないかな？
114名無しさん＠お腹いっぱい。NGNG
移植性を考える考えないの二択ではないでしょう。全プラットフォームの
全項目を保証する気なんてないし、不可能ですから、どこまでチェック
するかの問題ですね。AutoconfにしてもLibtoolにしても。
ですから「移植性考えないならlibtool使わなくていい」なんてのは極論です。
このチェックに関して言えば、ソースのビルド中にコマンドラインの
最大長を超えるコマンドは分割実行するようになっているみたいですが、
環境によっては数分以上かかるようなチェックをするより、4096とか
小さい値を決めうちしたほうがいいですね。実際そうしましたが。
コマンドに4096バイトも入らないプラットフォームは問題外ですから
無視でよいです。デフォルトがチェックになってるのは仕方ないですが。
115名無しさん＠お腹いっぱい。NGNG
外してたら済まんが、ac_cvなんとかでスキップできんの?
116名無しさん＠お腹いっぱい。NGNG
たかだか AC_LIBTOOL_SYS_MAX_CMD_LEN のチェックぐらいで数分もかかる
プラットホームは俺の中で問題外なんだけどなｗ
何のために libtool 使ってんのか分からんよ。
117名無しさん＠お腹いっぱい。NGNG
>>114
configure時の話なら、config.siteじゃできんかな？
lt_cv_sys_max_cmd_lenがキャッシュにあれば良さそうなんで、
test "$lt_cv_sys_max_cmd_len" = NONE && lt_cv_sys_max_cmd_len=4096
みたいな内容を書いとけばいいかもね。
# 試してないんで違うかもしれん。
# 今、バージョンの不一致でautotoolsがうまく動かない(泣)
118名無しさん＠お腹いっぱい。NGNG
autoconfのドキュメント読んでたら、
$ ./configure --lt_cv_sys_max_cmd_len=4096
でいけるかもしれんような気がした。
しかし、試せない。。。
119名無しさん＠お腹いっぱい。NGNG
やっと試せた。
>>118
> $ ./configure --lt_cv_sys_max_cmd_len=4096
ではなく、
$ ./configure lt_cv_sys_max_cmd_len=4096
だね。 120名無しさん＠お腹いっぱい。NGNG
libtool関係の質問はOKですか?>このスレ
121名無しさん＠お腹いっぱい。NGNG
すぐ上でされてるみたいだけど、とりあえずやってみれば？
問題があれば誘導されるでしょ。
122名無しさん＠お腹いっぱい。NGNG
configureのコストが、高機能になればなるほどデカクなってきてる
わけですが、これらを動的にチェックするんじゃなくて静的にデータ
ベースのようなもので持たせることはできないですかね。とはいっても
何かソフトウェアをインストールしたら、そこで内部状態は変わってしまう
わけでなかなか難しいんだろうけど。
123名無しさん＠お腹いっぱい。NGNG
>>122
そのためにはconfig.siteを使えばいいと思うんだけど。
124120NGNG
>>121
では、御言葉に甘えて。
ちょっとした理由で、安定版のXFCE4が入ってるシステムにCVS版のXFCE4を別にインストールしようと思ってます。
#安定版:パッケージで入れてるので/usr以下
#CVS版:ソースからコンパイルで/opt/xfce4以下
まず、libxfce4utilをインストールしました。(これで、libxfce4util.soは/usr/libと/opt/xfce4/libに存在）
次にlibxfcegui4とlibxfce4mcsをコンパイルしたのですが、libxfcegui4では、リンクの際に
/bin/sh ../libtool --mode=link gcc -g -O2 -o libxfcegui4.la -rpath /opt/xfce4/lib -export-dynamic
-version-info 2:0:1 -export-symbols-regex "^[^_].*" -L/usr/X11R6/lib -L/usr/X11R6/lib
libxfcegui4_la-dialogs.lo (略) libxfcegui4_la-gtkicontheme.lo -Wl,--export-dynamic
-lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0
-lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lSM -lICE -lX11 -lSM -lICE -lX11
-L/opt/xfce4/lib -lxfce4util -lglib-2.0 によって、
gcc -shared .libs/libxfcegui4_la-dialogs.o (略) .libs/libxfcegui4_la-gtkicontheme.o -L/usr/lib
-L/usr/X11R6/lib /usr/lib/libgtk-x11-2.0.so /usr/lib/libgdk-x11-2.0.so /usr/lib/libatk-1.0.so
/usr/lib/libgdk_pixbuf-2.0.so -lm /usr/lib/libpangoxft-1.0.so /usr/lib/libpangox-1.0.so
/usr/lib/libpango-1.0.so /usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so -ldl -lSM -lICE -lX11
-L/opt/xfce4/lib /usr/lib/libxfce4util.so /usr/lib/libglib-2.0.so -Wl,--export-dynamic -Wl,-soname
-Wl,libxfcegui4.so.1 -Wl,-version-script -Wl,.libs/libxfcegui4.ver -o .libs/libxfcegui4.so.1.1.0
と、/usr/lib/libxfce4util.soがリンクされます (続く) 125120(続き)NGNG
対してlibxfce4mcsでは、
/bin/sh ../libtool --mode=link gcc -g -O2 -o libxfce4mcs-manager.la -rpath /opt/xfce4/lib
-export-dynamic -version-info 2:0:1 -export-symbols-regex "^[^_].*" -L/usr/X11R6/lib
-L/usr/X11R6/lib libxfce4mcs_manager_la-mcs-channel.lo (略) libxfce4mcs_manager_la-mcs-manager.lo
-lSM -lICE -lX11 -lSM -lICE -lX11 -L/opt/xfce4/lib -lxfce4util -lglib-2.0 によって
gcc -shared .libs/libxfce4mcs_manager_la-mcs-channel.o (略) .libs/libxfce4mcs_manager_la-mcs-manager.o
-Wl,--rpath -Wl,/opt/xfce4/lib -Wl,--rpath -Wl,/opt/xfce4/lib -L/usr/lib -L/usr/X11R6/lib -lSM -lICE -lX11
-L/opt/xfce4/lib /opt/xfce4/lib/libxfce4util.so /usr/lib/libglib-2.0.so -Wl,-soname -Wl,libxfce4mcs-manager.so.1
-Wl,-version-script -Wl,.libs/libxfce4mcs-manager.ver -o .libs/libxfce4mcs-manager.so.1.1.0
と、/opt/xfce4/lib/libxfce4util.soがリンクされます。
この2つは、何がちがってリンクされるlibxfce4util.soが変わるのかがわからないのですが、どこを調べれば
いいのでしょうか？
126名無しさん＠お腹いっぱい。NGNG
pkg-configか？と脊髄反射してみる
128120NGNG
みなさん、すいません。
わからんわからんといいながら、解決してしまいました。
書き込みで両方のログをコピペしたときに、両方のlibtoolの部分の違いに気づいてしまいました。
「ん? -lhogeの前に-Wl,--export-dynamicがついてるな>libxfcegui4」
で、export-dynamicで調べてみると、
「動的リンクされた実行形式を作る時に, 全てのシンボルを動的シンボル表に追加する.」
とか書いてあって、よくわからなかったのですが、なんかリンクを動的にやろうとするから
/usr/lib/libxfce4util.soの方を見てしまうのかな?と思ったので、-lxfce4util の前に
export-dynamicがこないようにすればいいのかと思って-lxfce4utlがexport-dynamicの後に
くるようにしたところ、libxfcegui4.soが/opt/xfce4/lib/libxfce4utl.soにリンクするようになりました。
#実際にやったのは、libxfce4gui4/Makefile.inでのリンカの呼出で、gtkのリンクオプションと
#libxfce4utilのリンクオプションの順番を交換した
#(-Wl.-export-dynamicは"pkg-config gtk+-2.0 --libs"に含まれているため)
ということで、libtoolというより、なんかリンカの問題点だったような気もしてきた。
みなさん、お騒がせしました。
129神の愛の証言者 ◆IHSXPiND6Q NGNG
4ヶ月立ってもスレがDAT逝きしないとは素敵なスレですね。
さて、automake で bison をいじろうとしています。
確かに
Makefile.am に
parser_SOURCES = parser.y lexer.l
と書くと bison/flex がたちあがって parser.c / lexer.c を吐き出し、
さらにこいつらが実行可能形式にコンパイルされるわけですが、
make clean で parser.c / lexer.c が消えない。
おまけに
AM_YFLAGS = -dで parser.y から parser.h を生成しても、
その依存関係が Makefile に記述されていません。
1. make clean, make dist とかで parser.c, lexer.c を消す方法
2. parser.h と parser.y の依存関係を Makefile に記述させる方法
を教えて下さい。
130神の愛の証言者 ◆IHSXPiND6Q NGNG
>>129
自己レス
parser.c とか lexer.c を消したいなら
make maintainer-clean
を使うとよい。
ただし、なんで clean と maintainer-clean が別なのかその理由が分からない。
automake が吐き出す Makefile はちゃんと parser.y と parser.h の依存関係を
理解している。ただし、互換性維持のために
parser.ht という新しいヘッダファイルを一旦生成し、
元からある parser.h と比較して、
内 容 が 本 当 に 違 っ て い た 場 合 に 限 り
parser.h を上書きする。だから、単に parser.y のタイムスタンプを新しくしても
parser.h は更新されない。 131名無しさん＠お腹いっぱい。NGNG
なんでこんなにたくさんバージョンがあるんだろう。
使いづらくてかなわん。
132保守NGNG
>>131
ヴァージョンがたくさんあるのは、上の方で言われている通り、
後方互換性(backward compatibility)が維持できていないからですね。
使いにくいのは>>81さんの通りかと;-) 133名無しさん＠お腹いっぱい。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に関係するソースを無視させるにはどうやったら良いでしょうか？
134名無しさん＠お腹いっぱい。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
あたり。
135133NGNG
>>134
キモはAM_CONDITIONALとifの組み合わせだったのですね。
やりたいことが実現できてすっきりです。ありがとうございます。 136名無しさん＠お腹いっぱい。NGNG
あるプログラムは C、あるプログラムは シェルスクリプト、あるプログラムは Perl を使って書かれた
パッケージを autoconf, automake でインスコさせたい時、
シェルスクリプトとか Perl に関する指示はどう出せばいいんですか?
137名無しさん＠お腹いっぱい。NGNG
Makefile.amに
bin_SCRIPTS = fugafufu.pl
とか？
138名無しさん＠お腹いっぱい。NGNG
嘔吐makeなんか嫌いだ～
手書きで書けYO!!
139名無しさん＠お腹いっぱい。NGNG
AC_CHECK_SIZEOF(wchar_t) の結果を Makefile(.am) 内で知りたいのだが、
何かうまい方法はないもんですかね・・・。
（wchar_t のサイズが Linux と Cygwin で違うから、コンパイルするファイルを
振り分けたい、というのが動機です）
140名無しさん＠お腹いっぱい。NGNG
まだあったのか、このスレ。
>>138
make組ハケーン
>>139
AM_CONDITIONAL 141139NGNG
>>140
レスどうもでつ。
結局 AC_CANONICAL_HOST で逃げることにしますた。 142名無しさん＠お腹いっぱい。2005/05/05(木) 14:20:02
143名無しさん＠お腹いっぱい。2005/05/07(土) 09:54:27
-lhogeでstatic-linkさせる方法を教えて下さい。
144名無しさん＠お腹いっぱい。2005/05/07(土) 12:38:59
>>143
自作のライブラリなら，
hoge_LDFLAGS = -static
をMakefile.amに追加するのかな？
make時なら，./configure --helpして
それなりのオプションがあれば可能だと思う．
145名無しさん＠お腹いっぱい。2005/05/07(土) 23:00:52
ありがとうございました
146名無しさん＠お腹いっぱい。2005/05/08(日) 14:02:17
共有ライブラリのバージョンが違っても動くプログラムを作る方法を教えて下さい
147名無しさん＠お腹いっぱい。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等の指定の仕方が変わったのでしょうか？
＃なにか指定し忘れてるのだろうか,,,
148名無しさん＠お腹いっぱい。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あたりに何故できないかの情報があるかもしれないので、
ながめてみてください。
1491472005/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 を使っていようと思います。ありがとうございました。 150名無しさん＠お腹いっぱい。2005/05/10(火) 00:16:22
>>149
あまりお役に立てなかったようで、、、
後は、ソースからビルドされたようなので、
libtoolのmakeに失敗している可能性もあるので、
libtoolをmakeしたディレクトリでmake checkして、
問題が無いか確認するぐらいかな？
151名無しさん＠お腹いっぱい。2005/05/12(木) 00:45:45
↓の書き込みも漏れだったりするけど、多分これだと思う。
540 名前：名無しさん＠お腹いっぱい。：05/02/05 01:29:46
>539
そもそも X 自体入れてないんでどうなんか知らんが。
作らないんじゃなくて、作るけどわざわざ入れないようだ。
devel/libtool15 にわざわざ .la をインストールしないようパッチがされてる。
参考: http://www.freebsd.org/cgi/query-pr.cgi?pr=76363
とりあえず x11/libxfce4/Makefile で
-USE_LIBTOOL_VER=15
+USE_INC_LIBTOOL_VER=15
してやれば .la も入るみたいだけど？
152名無しさん＠お腹いっぱい。2005/05/12(木) 00:46:58
>151
あー、ごめん早とちりしたかも。
153名無しさん＠お腹いっぱい。2005/05/25(水) 21:12:32
154名無しさん＠お腹いっぱい。2005/06/23(木) 12:44:19
autopoint で i18n 化した場合って、GPL 互換のライセンスにしないと駄目なの？
intl/ の下に出来るファイルは全部 GPL だよね？
ソフトウェア本体のライセンスは Apache License 2.0 にしたいんだけども。
155名無しさん＠お腹いっぱい。2005/06/23(木) 18:12:59
>>154
info gettextのDiscussionsの
* Dependencies over the GPL or LGPL
に[The simplest answer is "normally not".]と書かれている。
一応、読んでみてね。 156名無しさん＠お腹いっぱい。2005/06/23(木) 18:32:19
>>155
thx。でも英語が分からん…＿|￣|○
一応読んでみたんだけど、intl/ を含めなければ GPL/LGPL 以外でも
配布できるという解釈で OK?
157名無しさん＠お腹いっぱい。2005/06/23(木) 20:25:51
158名無しさん＠お腹いっぱい。2005/06/24(金) 01:56:18
よくわからんが、intlの下ってlibintlに入るものと同じなんでしょ?
削ってしまってlibintlを動的リンクすれば何でもいいんじゃないの?
159名無しさん＠お腹いっぱい。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
160名無しさん＠お腹いっぱい。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
161名無しさん＠お腹いっぱい。2005/10/18(火) 15:51:25
>>159
subB1.oをリンクし忘れてるとか
リンクの際に引きわたす.oの順番を変えてみるとか
162名無しさん＠お腹いっぱい。2005/10/18(火) 16:31:26
Makefile.am での”xxx_LIBRARIES =, xxx_SOURCES =”や
configure.in での”AC_CONFIG_FILES()”以外に、
リンク先の指定方法があるのでしょうか？？
なんとなく、各 Makefile.am でリンク先の指定とか
できそうに思うのですが、調べても判りません orz。
163名無しさん＠お腹いっぱい。2005/10/20(木) 22:59:06
>>159
なんでそんな不思議な事を…
programBのツリー内でlibprogramB.aでも作ればいいんじゃない 164名無しさん＠お腹いっぱい。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
165名無しさん＠お腹いっぱい。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
166名無しさん＠お腹いっぱい。2005/10/22(土) 09:40:24
>>164
共通部分はライブラリにしてしまうのがいいと思うのだが、
後、SOURCESなどでは相対パスではなく、$(top_srcdir)
などを利用するのが、最近の流儀です。
# configureを任意のディレクトリで実行可能にするため。
また、SUBDIRSがサブディレクトリではないのも問題になるかも
しれません。
パッケージ構成を再検討したほうがいいと言うのに私も賛成。 167名無しさん＠お腹いっぱい。2005/10/22(土) 20:26:11
自己解決しました。
*.cc ファイルと *.c ファイルが混在してたのに extern "C" {} で囲んで
なかったのが原因のようですた。これで make が通るようになり pgA が
出来上がったのですが、いまいち腑に落ちないです。なんかちょっと
書き換えただけでエラーの表示内容が変化するので何が悪いのか判りにくい…。
まあ、自分が悪いのですが。 お答えいただいた皆さんありがとう
ございました。
168名無しさん＠お腹いっぱい。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 なんてそんなもの
169名無しさん＠お腹いっぱい。2006/03/27(月) 21:49:45
>>168
LIBSをunsetしてから
LIBS=hoge ./conifgure
とすると、サブのconfigureに引き継がれないという噂が
利用できるかもしれないが、そうでなければ、
> 1. LIBS を環境変数として指定するのは間違い
かな？
> 3. autoconf なんてそんなもの
これの気もするが、、、
170名無しさん＠お腹いっぱい。2006/03/28(火) 17:34:44
> LIBS=hoge ./conifgure
だめみたい。
うーん、configure.ac で
LIBS="$LIBS_EXTRA $LIBS"
するのを止めて、Makefile.in で、
LIBS = @LIBS_EXTRA@ @LIBS@
しないとだめなのかなぁ。
ぶー、ぶさいく。
171名無しさん＠お腹いっぱい。2006/03/32(土) 13:15:03
./configure LIBS=hoge
172名無しさん＠お腹いっぱい。2006/03/32(土) 15:03:08
ちらしの裏に書いて置くべきことなは、
承知のうえで、あえて、誰かに聞いてもらいたい。
Autoconf,Automake,libtoolのおかげで、コンパイル、インストール
は確かに楽になってると思うんだけど、自分でソース弄りたいなぁ
って思うときに、なんかわけわからなくて。
makefileを自作してたりする。んでそれが面倒なんでソース弄るのも
おっくうになってたり。
みんなはどうしてるの？
173名無しさん＠お腹いっぱい。2006/03/32(土) 15:15:07
自分で書くCソースはそもそもそんなに複雑じゃないので、
autoconfを使わなくてもMakefileはOSに依存せず、
異なるOS間でも共通(同一)になることが多い。
なので、Makefileを自分で直接書いてる。
もしくは、もっと簡単なソースだとMakefileすら要らず、
makeのデフォルトルールだけで make hoge 一発でできてしまうことも多いが。
174名無しさん＠お腹いっぱい。2006/03/32(土) 17:58:32
>>172
使い方覚えれば自分でソースいじるときもAutotoolsは便利だよ
ソースの依存関係なんてちょっと大きなプロジェクトになると自分で書いてられん
とは言っても最初のmakeにたどり着くまでの作業はちょっと億劫なので
それを自動化したprepare_projectなるスクリプトを書いて使ってる
175名無しさん＠お腹いっぱい。2006/04/02(日) 06:43:54
autoconfは便利だしとっつきやすいが、
automakeまで手を伸ばすのはちと面倒なんだよな。
どうせ最初から使う必要なんてないんだから、
必要を感じてきたらそのとき導入すればいいよ。
>> prepare_projectなるスクリプト
MS的にいうとautotools_wizardだね
176名無しさん＠お腹いっぱい。2006/04/02(日) 12:22:16
177名無しさん＠お腹いっぱい。2006/04/03(月) 03:18:57
>>175
autoconf単独よりautomakeとセットで使う方が断然らくちんだべや 178名無しさん＠お腹いっぱい。2006/04/07(金) 23:19:18
NFS上でaclocal等を実行すると、perlがflock使っているところで
止まるんだけど、これってperlを-Ud_flock付きでコンパイルする
以外に方法はないのでしょうか？ (aclocalは1.9.6)
179名無しさん＠お腹いっぱい。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の間の書き方が分かりません。
よろしくお願いします。
180名無しさん＠お腹いっぱい。2006/07/18(火) 14:34:27
>>179
configureの時点で止めてしまうって話でいいのなら、下の感じだとおもう。試してはいないけど。
AC_CHECK_SIZEOF(int)
if test $SIZEOF_INT != 4; then
AC_MSG_FAILURE([aaaa])
fi
1811792006/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
としてみたらうまくいきました。ありがとうございました。 182名無しさん＠お腹いっぱい。2006/07/20(木) 20:39:59
183名無しさん＠お腹いっぱい。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にするといいらしい。
とりあえず、こんな状況。
184名無しさん＠お腹いっぱい。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
となってしまいます、、
185名無しさん＠お腹いっぱい。2006/11/24(金) 06:20:37
AC_DEFINE_UNQUOTED
186名無しさん＠お腹いっぱい。2006/11/24(金) 06:35:43
今も聞こえる オウトマケの唄
187名無しさん＠お腹いっぱい。2006/11/25(土) 03:01:50
>>185
変更したら解決できました。
ありがとうございます。 188名無しさん＠お腹いっぱい。2006/12/03(日) 05:15:59
AC_CHECK_LIBに/usr/local/libなどのディレクトリも見てもらうようにするには
どうしたらいいんでしょうか？
189名無しさん＠お腹いっぱい。2006/12/08(金) 09:17:54
そもそも、
AC_CHECK_HEADERSがヘッダを探すサーチパス、
AC_CHECK_LIBがライブラリを探すサーチパス、
は、
どこで定義されていて、
どうやったらそこに任意のディレクトリを追加できるのでしょう？
ドキュメントには記述が発見できず...
190名無しさん＠お腹いっぱい。2006/12/08(金) 14:19:02
apacheやqmailみたいに１パッケージに複数のアプリケーションが含まれているようなソースツリーの場合にいい感じにconfigureを量産してくれるようなautotoolsが欲しい。
191名無しさん＠お腹いっぱい。2006/12/08(金) 20:42:36
/usr/share/autoconf とかその辺にあるよ
192名無しさん＠お腹いっぱい。2006/12/09(土) 22:48:56
>>191
ありがとうございます。
/usr/share/autoconf/autoheader.m4f にそれらしき部分を見つけました。
/usr/share を変更できない権限で configure 実行時にサーチパスを追加
する方法を探しています。
環境変数INCLUDEにセットしてみたり、
./configure INCLUDE=hoge
とかやってみているのですが、うまくいかずです。
193名無しさん＠お腹いっぱい。2006/12/13(水) 15:01:54
./src
main.c
./others
hoo.h
という階層があって、main.cからhoo.hを読み込んでいるのですが、Makefile.am
はどのように書けばいいのでしょうか？
194名無しさん＠お腹いっぱい。2006/12/13(水) 15:03:01
すいません書き忘れです。
./others
hoo.h
hoo.c
という感じです
195名無しさん＠お腹いっぱい。2006/12/14(木) 04:27:56
>>192
環境変数で解決しました。
AC_CHECK_HEADERS は CPPFLAGS=-I<include_dir>、
AC_CHECK_LIB は LIBS=-L<lib_dir>
で設定したディレクトリを探してくれるようです。 196手元にある本から・・・2006/12/16(土) 18:51:20
197名無しさん＠お腹いっぱい。2006/12/16(土) 19:59:25
>>196
ありがとうございます
どうにも良く分からないので
./src
main.c
./others
hoo.h
hoo.cpp
を、libothers.aとライブラリにして、./srcでリンクさせてます。（リンクが成功しないんですがこれは別問題かと）
うーむ、実際にautotoolsで作ってる人はどうしてるんだろうか
198名無しさん＠お腹いっぱい。2006/12/16(土) 20:55:20
>>196,197
今試したら少なくともautomake-1.9.5だと
うまくサブディレクトリを扱えるみたい
199名無しさん＠お腹いっぱい。2006/12/17(日) 04:04:49
具体的な書き方が分からないのですが、教えていただけませんか？
200名無しさん＠お腹いっぱい。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
2011982006/12/17(日) 18:48:32
>>199
具体的もなにもmain.cのあるディレクトリのMakefile.amで
hoge_SOURCES=main.c others/hoo.h others/hoo.cpp
するだけだよ
othersにあるファイルも同じように扱えるようになったみたいなので
わざわざライブラリにまとめる必要はない
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
221名無しさん＠お腹いっぱい。2007/07/23(月) 21:04:35
まず問いたい。
おまえはそれを見て、それが正解だと推測したわけだよな？
公式のマニュアルではなく、なぜそんな下らんもので推測したんだ？
222名無しさん＠お腹いっぱい。2007/07/23(月) 22:30:52
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
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
245名無しさん＠お腹いっぱい。2015/01/03(土) 09:15:56.58
246名無しさん＠お腹いっぱい。2015/01/03(土) 21:25:10.13
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.
ブックマークへ