このくらいの知識で、教材のトラブルシューティングがいけるかなぁ。
** 3 General ideas
- Automakeの動作について、基本的な考え方を紹介す
る。
*** 3.1 General Operation
- Automakeは`Makefile.am'を読み込み、
`Makefile.in'を生成する。
- `Makefile.am'で定義された変数やルールを拠り所に
して、Automakeが追加的なコードを生成することも
ある。
- 例えば、`bin_PROGRAMS'変数があると、Automakeは、
コンパイルとリンクのルールを追加する。
- `Makefile.am'の中身(変数とルールの定義)は、その
まま、`Makefile.in' にコピーされる。
- 自動生成された、`Makefile.in'に、手でルール等を
追加することは問題ない。
- Automakeは、ほとんどのGNU make拡張を認識しない。
すなわち、`Makefile.am'に書くとエラーになる。唯
一の例外は、+=演算子。
- Makefile.amで定義したルールの名前が、automake が
自動生成するルールの名前と衝突していた場合、
Makefile.amのものが優先される。名前の衝突は避け
るべきである。
- 同様に、Makefile.amの変数定義またはconfigure.ac
のAC_SUBSTされた変数定義が、automakeが自動生成す
るものと衝突していた場合、前者が優先される。
- Automakeの変数展開はmakeと同じ(ようだ)。
- ##で始まる行をAutomakeは無視する。(先行してスペー
スがあっても同じ)
*** 3.2 Strictness
- strictnessは、the GNU standardsへの準拠を
Automakeがどれだけ厳格に取り扱うかという指標。
- 使える値は次のもの。
- foregin : Automakeが動作するのに必要最低限な
チェックだけを実施。
- gnu : the GNU standardsに適合しているか可能な
かぎりチェックする。デフォルト。
- gnits : Gnits standards (策定中)に適合してい
るかチェックする。Gnits standardsはthe GNU
standardsをベースとし、より詳細である。
*** 3.3 The Uniform Naming Scheme
- Automakeの変数は、uniform naming schemeに従って
いる。
- この命名則に従えば、名前によって、「make time」
において、そのプログラムを如何ように構築すべきか
が判別できる。
- また、この命名則は、「configure time」において、
何を構築すべきかということの判断することを助け
る。
- この命名則では、名前はいくつかの部分からなる。
- 何を構築すべきかということを示す部分を"primary"
と呼ぶ。PROGRAMSというprimaryは、コンパイルとリ
ンクが必要なものであることを示す。
- primaryの前に'EXTRA_'をつけることができる。これ
は、maybe builtという意味であり、実際にbuildす
るかどうかはconfigureが決める。
- 他の部分には、built objectsをシステム上のどこに
格納するのかを示すものがある。primaryのprefixに
なる。「どこに」として選択できるかきぶりは、the
GNU standardsできまっているディレクトリ構成に準
拠すべし。
- noinst_をつけると、構築されるが、インストールは
されない。
- check_をつけると、make check済みでないと構築さ
れない。make check済みだと、noinst_と同様の振舞。
- primary namesの一覧
`PROGRAMS', `LIBRARIES', `LISP', `PYTHON',
`JAVA', `SCRIPTS', `DATA', `HEADERS', `MANS',
and `TEXINFOS'.
- いくつかのprimaryには、`dist_', `nodist_',
`nobase_'というprefixが使える。これらによって、
automakeの振る舞いを制御できる。
*** 3.4 Staying below the command line length limit
- unix-likeシステムでは、プロセス生成時にリソース
制限がある。具体的には、コマンドライン引数の長
さや環境情報(環境変数など)のサイズだ。
- POSIXの要求は、少くとも4KB確保。実際のシステム
の上限はもっと高い。
- ポータビリティを考えると4KB以内になるようにすべ
き。
- Automakeの機能だけでは、これを達成できない。
- そのためのMakefile.amのかきぶりの注意点など。
*** 3.5 How derived variables are named
- 値由来の名前をもとにして、Automakeが新な名前をつ
くるときのルール。
- 例えば、_PROGRAMSが格納するリストをもと
に、_SOURCESの名前をつくるとき、大抵の記号は'_'
になる。
- 例：
'snif-glue'が'_PROGRAMS'にあると
き、'snif_glue_PROGRAMS'という名前をつく
る。'snif-glue_PROGRAMS'では無い。
*** 3.6 Variables reserved for the user
- the GNU Coding Standardsでは、ユーザ用の変数を定
めている。メンテナはこれを使うべきではない。
- 例えば、'CFLAGS'。
- Automakeは、ユーザ用変数のシャドウ変数を用意し
ている。メンテナはこちらを使う。シャドウ変数は、
AM_で始まる。例えば、'CFLAGS'のシャドウ変数
は、'AM_CFLAGS'。
*** 3.7 Programs automake might require
- Automakeを使って作成したMakefileが正しく動作す
るためには、ヘルパープログラムが必要になること
がある。これはその一覧。これらはAutomakeと一緒
に配布されている。
`ansi2knr.c'
`ansi2knr.1'
`compile'
`config.guess'
`config.sub'
`config-ml.in'
`depcomp'
`elisp-comp'
`install-sh'
`mdate-sh'
`missing'
`mkinstalldirs'
`py-compile'
`symlink-tree'
`texinfo.tex'
`ylwrap'
** 4 Some example packages
*** 4.1 A simple example, start to finish
- Autoconfは使っているが、Automakeはまだ使ってい
ないという状況において、どのようにAutomakeを導
入するかというシナリオ。
*** 4.2 Building true and false
- true.cというひとつのソースから、trueとfalseとい
う2つのプログラムをbuildするためのMakefile.amの
かきぶり紹介。(なぜ、ここでこんなものを紹介する
のか理解できない。。。)
** 5 Creating a 'Makefile.in'
- Makefile.inを生成するには、トップレベルディレク
トリにて'automake'を実行すればよい。
- automakeは、configure.acをscanして、Makefile.am
を探し出す。
- ただし、configure.acが複数存在するようなプロジェ
クトというか構成においては、それらはおそらくサブ
プロジェクトを運用しているということなのだが、
configure.acが存在するディレクトリ毎にautomakeを
実行しなければならない。
- さらにただし、autoreconfをつかうと、
configure.acに記述されているconfigure.ac間の依
存関係から自動的にautomakeも再帰処理してくれる。
- automakeは常にトップレベルディレクトリで実行し
なければいけない。そうしないと、大元の
configure.acが存在するディレクトリとの出入りな
どを勘案できないからだ。
- Automakeはconfigure.acをscanするために、
autoconfを走らせる。(scanするためだけ)
- Automakeのオプション一覧
`-a'
`--add-missing'
`--libdir=DIR'
`-c'
`--copy'
`--cygnus'
`-f'
`--force-missing'
`--foreign'
`--gnits'
`--gnu'
`--help'
`-i'
`--ignore-deps'
`--include-deps'
`--no-force'
`-o DIR'
`--output-dir=DIR'
`-v'
`--verbose'
`--version'
`-W CATEGORY'
`--warnings=CATEGORY'
`gnu'
`obsolete'
`override'
`portability'
`syntax'
`unsupported'
`all'
`none'
`error'
上記のものに'no-'をつけると除外指示。
** 6 Scanning 'configure.ac'
*** 6.1 Configuration requirements
- Automakeを使うために、configure.acがどうあるべ
きかという話。
- 唯一必須は、'AM_INIT_AUTOMAKE'マクロ。
- その他にもautomakeが必要とするマクロがある。
- `AC_CONFIG_FILE'
- `AC_OUTPUT'
- この2つのかきぶりはこんな感じ。configure.acの
末尾。
...
AC_CONFIG_FILES([
Makefile
doc/Makefile
src/Makefile
src/lib/Makefile
...
])
AC_OUTPUT
- AC_CONFIG_FILESの引数で指定されているMakefile
がautomakeの生成対象となる。なので、同じパス
にMakefile.amが存在することが期待され、同じパ
スにMakefile.inを生成する。
- AC_CONFIG_FILESの引数に変数を使うときは要注意
どう展開させるかどうかという制御が必要。その
制御にはAC_SUBSTを使う。詳細は割愛。
*** 6.2 Other things Automake recognize
- configure.acに書き得る内容で、Automakeが生成す
るMakefile.inに影響を与えうるものどもの一覧。
`AC_CANONICAL_BUILD'
`AC_CANONICAL_HOST'
`AC_CANONICAL_TARGET'
Automakeは、config.guessとconfig.subが存在すること
を保証する。(なければ作るということか？)
build_triplet, host_triplet, target_tripletという
変数を導入する。
`AC_CONFIG_AUX_DIR'
helper scriptsを探すにあたって、これの引数に指定さ
れたディレクトリを対象とする。このマクロが無い場合、
標準配置場所(ものによって異なる)を探す。
`AC_CONFIG_LIBOBJ_DIR'
このマクロの引数で指定するディレクトリ
`AC_LIBSOURCE'
Automake will require the sources file declared with
`AC_LIBSOURCE' (see below) in the directory specified by this
macro.
`AC_CONFIG_HEADERS'
Automakeは、ここで指定されたヘッダを作成するための
ルールを生成する。
`AC_CONFIG_LINKS'
Automakeは、ルールをつくる。このルールは、
configureが生成したリンクを'make distclean'で削除
し、'make dist'で、ソースファイル(リンクじゃないと
いうこと？)を配布物に含める。
`AC_LIBOBJ'
`AC_LIBSOURCE'
`AC_LIBSOURCES'
Automakeは、`AC_LIBSOURCE' または `AC_LIBSOURCES'
に含まれているファイルを配布物に含める。
`AC_LIBOBJ'は`AC_SIBSOURCE'を呼び出す。そのため、こ
れで指定したものも配布物に含まれる。
`AC_PROG_RANLIB'
ライブラリを構築するなら必要。
`AC_PROG_CXX'
C++のソースが含まれているなら必要。
`AC_PROG_OBJC'
Objective Cのソースが含まれているなら必要。
`AC_PROG_F77'
Fortran 77のソースが含まれているなら必要。
`AC_F77_LIBRARY_LDFLAGS'
ホスト言語はFortran 77ではないが、Fortran 77のコー
ドを含むようなプログラムやライブラリのソースが含ま
れているなら必要。
`AC_PROG_FC'
Fortran 90/95のソースが含まれているなら必要。
`AC_PROG_LIBTOOL'
libtoolのための処理をAutomakeは実行する。
`AC_PROG_YACC'
Yaccソースが含まれているなら、これを使うか、
configure.acで'YACC'変数の定義が必要。
`AC_PROG_LEX'
Latexのソースが含まれているなら必要。
`AC_REQUIRE_AUX_FILE'
`automake' will ensure each file for which this macro is called
exists in the aux directory, and will complain otherwise. It will
also automatically distribute the file. This macro should be used
by third-party Autoconf macros that requires some supporting files
in the aux directory specified with `AC_CONFIG_AUX_DIR' above.
*Note Finding `configure' Input: (autoconf)Input.
`AC_SUBST'
第一引数で指定した変数名を、すべてのMakefile.inで
変数として定義する。
`AM_C_PROTOTYPES'
旧式となったde-ANSI-ficationを使うには必要。
`AM_GNU_GETTEXT'
GNU gettextをつかっているパッケージでは必要。
`AM_GNU_GETTEXT_INTL_SUBDIR'
AM_GNU_GETTEXTの引数でexternalを指定していても、
intl/サブディレクトリを構築する。
`AM_MAINTAINER_MODE'
`--enable-maintainer-mode'オプションが`configure'
に装備されるようにする。すなわち、automakeは
"maintainer-only"ルールを生成する。
`m4_include'
configure.acがこのマクロでincludeしているファイル
を、配布物に含めるようにする。
*** 6.3 Auto-generating aclocal.m4
- Automakeは、多数のAutoconfマクロを含んでいる。
(なぜそんなことに。。。)
- なので、Autoconfからそれらを使えるようにしてあ
げなければならない。AutomakeはAutoconfを使うの
で、Automakeが正常動作するためにもこのことが必
要。
- これを実現するのがaclocalプログラム。
- aclocalは、configure.acを読み込んで、その内容に
応じて、aclocal.m4 filesを作成する。
- これがあるとautoconfはマクロを見付けることがで
きる。
- aclocalはm4マクロがあるべき(あるかも)場所をすべ
て探索する。
- autom4teは、マクロの利用をトレースし、不要なも
の(使われないもの)をaclocal.m4から削除する。
**** 6.3.1 aclocal Options
`--acdir=DIR'
`--diff[=COMMAND]'
`--dry-run'
`--help'
`-I DIR'
`--install'
`--force'
`--output=FILE'
`--print-ac-dir'
`--verbose'
`--version'
`-W CATEGORY'
`--warnings=CATEGORY'
**** 6.3.2 Macro Search Path
- aclocalがm4マクロを探す場所一覧。
`acdir-APIVERSION'
これはAutomakeに同梱されているAC_マクロの置き場所。
`acdir'
サードパーティの.m4ファイルのための場所。
***** 6.3.2.1 Modifying the macro search path: `--acdir'
- これはメンテナが使うものなじゃない。Automakeの
内部利用のためのもの。
***** 6.3.2.2 Modifying the macro search path: `-I DIR'
- これはメンテナが使うもの、DIRが探索先として
prependされる。
***** 6.3.2.3 Modifying the macro search path: `dirlist'
- dirlistファイルがaclocalのm4探索パスにある場合、
そのファイルの中身の指示を探索先に含める。指示
はパターン(シェルの正規表現)で指定する。この探
索先は既存の探索先にappendされる。
**** 6.3.3 Writing your own aclocal macros
- 例えば、自分のパッケージを他のメンテナが利用する
ときに便利なm4マクロを書いたとしよう。そのm4 マ
クロもパッケージに同梱して配布し、aclocalの探索
対象とすることができる。そのやり方。
- 拡張子は`.m4'。
- インストール場所は、`$(datadir)/aclocal'。
- その他、AC_的なオリジナルm4マクロを書くための作
法を紹介。
**** 6.3.4 Handling Local Macros
- Autoconfが提供する機能テストがどんなプロジェク
トでも十分なものである、ということはアタリマエ
だがありえない。
- 往々にして、メンテナは、自分でマクロを書いて補
完することになる。またはサードパーティのマクロ
を使うことになる。
- この際、やり方が2つある。
- ひとつめ。
- acinclude.m4に書く。これはaclocal.m4が取り込ん
でくれる。
- ただし、マクロの数が増えると、1ファイルでそれを
管理するのは面倒になる。
- ふたつめ。こちらが推奨。
- マクロをファイルに分けて、それをm4/というディレ
クトリにまとめる。で、'aclocal -I m4'する。
- その他、ローカルマクロに関する複雑な事情の説明。
- で、それを回避するためには、configure.acに、
ACLOCAL_AMFLAGS = -I m4 --install
と書きましょう、ということ。
- マクロのシリアル番号を入れておくと、
aclocalは'--install'オプションがついていると、そ
れを見て更新すべきかどうかを判断してくれる。
- シリアル番号はマクロファイルの中に、マクロ定義
が出てくる前の位置に書く。
#serial NNN
NNNは数字または'.'。
**** 6.3.5 Serial Numbers
- シリアル番号に関する詳細。
**** 6.3.6 The Future of aclocal
- aclocalは将来消滅すべきである。とくに、これは
Automakeがやるべきことではない。Autoconfがやる
べきことだ。
- ただし、aclocalに依存したサードパーティアプリケー
ションがあったり、ディレクトリ構造があったりす
る。そういった事情の説明。
*** 6.4 Autoconf macros supplied with Automake
- この節は割愛。
**** 6.4.1 Public Macros
**** 6.4.2 Obsolete Macros
**** 6.4.3 Private Macros
** 7 Directories
- 複雑もしくは大規模なプロジェクトでは、プログラ
ムやライブラリ毎にディレクトリをわけて、再帰的
にbuildをする。その方法について。
*** 7.1 Recursing subdirectories
- サブディレクトリに再帰する場合は、親ディレクト
リの'Makefile.am'に、
SUBDIRS = doc intl src test
などと書く。
- AutomakeはSUBDIRSをdepth-firstでディレクトリ構
造を処理していく。するとテストのように全てがビ
ルドされたあとにビルドすべきものが厄介だ。根の
ディレクトリのMakefile.inの作成は、ディレクトリ
ツリーから言えば、一番最後になるから。対処は簡
単。
SUBDIRS = doc intl src . test
*** 7.2 Conditional Subdirectories
- パッケージによっては、ビルドするものを「基本」と
「オプション」と分けたい場合もある。使わないもの
をビルドしてもしょうがないし。
- この節はその手法について。
- 手法は2つ。
- ひとつめは、Automake conditionalsを使う方法。こ
ちらが推奨。
- ふたつめは、Acutoconf AC_SUBST変数を使う方法。
- これらを説明するまえに、DIST_SUBDIRSを紹介。
**** 7.2.1 SUBDIRS vs. DIST_SUBDIRS
- SUBDIRSに含まれるのはビルド対象ディレクトリ。
- DIST_SUBDIRSに含まれるのは、配布対象ディレクト
リ。
- SUBDIRSがAutomake condigionalsによって、条件分岐
する形で書かれている場合、DIST_SUBDIRSには、それ
を勘案してビルドの可能性があるすべてディレクトリ
が含められる。
- 'make mainainer-clean', 'make distclean', 'make
dist' は再帰にあたってDIST_SUBDIRSを使う。それ
以外のターゲットは、SUBDIRSを使う。
- AC_SUBSTをSUBDIRSの引数につかっていると、
DIST_SUBDIRSはうまく動作しない。
**** 7.2.2 Subdirectories with AM_CONDITIONAL
- さて、Automake conditionalsの方法。
- たとえば、src/配下は常にビルド、opt/以下は指定
されればビルドとしたいとする。
- すると、configure.ac(？)には次のように書く。
...
AM_CONDITIONAL([COND_OPT], [test "$want_opt" = yes])
AC_CONFIG_FILES([Makefile src/Makefile opt/Makefile])
...
- そして、トップレベルのMakefile.amで次のようにす
る。
if COND_OPT
MAYBE_OPT = opt
endif
SUBDIRS = src $(MAYBE_OPT)
**** 7.2.3 Conditional Subdirectories with `AC_SUBST'
- AC_SUBSTを使う方法
- configure.ac(？)にはこう書く。
...
if test "$want_opt" = yes; then
MAYBE_OPT=opt
else
MAYBE_OPT=
fi
AC_SUBST([MAYBE_OPT])
AC_CONFIG_FILES([Makefile src/Makefile opt/Makefile])
...
- Makefile.amはこう書く。
SUBDIRS = src $(MAYBE_OPT)
DIST_SUBDIRS = src opt
- DIST_SUBDIRSは、手で設定しなければならない。
**** 7.2.4 Unconfigured Subdirectories
- ここでいうconditonalsというのは、buildするかど
うかということでありconfigureは全ての対象につい
て行う。
- よくある誤解は、configureもconditionalにできるの
では(もしくはそうなっているのでは)と考えてしまう
こと。
- configureをconditionalにするのは、かなりトリッ
キー。初心者はやるべきではない。
- その説明を少々。
*** 7.3 An Alternative Approach to Subdirectories
- 再帰的makeはよろしくないという考えもある。再帰
的makeは遅いし、error-proneであるという。
- 単一のMakefileで複数のディレクトリをカバーする
のがよいという。
- Automake はこの方式にも対応している。
- しかしまだ枯れていない。バグがちょこちょこ出て
いる。
- 実現方法の説明。
*** 7.4 Nesting Packages
- the GNU Build Systemでは、パッケージを任意の深
さまでネストできる。
- ただし、親プロジェクトの中に子プロジェクトのパッ
ケージが配置されており、親プロジェクトのSUBDIRS
に子プロジェクトのディレクトリが含まれているこ
とが必要。
- また、子プロジェクトのconfigureを生成するには、
configure.acにAC_CONFIG_SUBDIRSを書いて指定する
必要がある。
** 8 Building Programas and Libraries
*** 8.1 Building a program
- programをbuildするには、Automakeに、ソースがど
れか、リンクすべきライブラリがどれかを伝えなけ
ればならない。
**** 8.1.1 Defining program sources
- programsがインストールされうる場所は次のとおり。
bindir, sbindir, libexecdir, pkglibdir,
pkglibexecdir
- どこにもインストールしない(noinst_)という選択
肢もある。
- テストのためだけにビルドする(check_)という選
択肢もある。
- PROGRAMS primaryを用いる。
- 例。
bin_PROGRAMS = hello
- このときMakefile.inは、helloという名前のprogram
をビルドするコードを含む。
- この行が存在すると、このhelloという名前に関連し
たいくつかの変数が存在することが暗黙のうちに真
となる。
- それら変数は、Makefile.amにおいてはオプショナル
でありデフォルト値を持つ。それらを見ていく。
- hello_SOURCES
- デフォルト
hello_SOURCES = hello.c
- 手動設定例
hello_SOURCES = hello.c getopt.c getopt.h system.h
- こう書くと自動的に.c達から.oを生成するよう
になる。
- SOUCESに含まれているヘッダファイルは、配布物
に内包される。含まれていないヘッダは内包され
ない。
- configureが生成するヘッダ(config.hのこと？)は、
SOURCESに含めるべきではない。これは配布すべき
ものではないから。
- Lex(.l)とYacc(.y)ファイルもSOURCESに含めるこ
とができる。
**** 8.1.2 Linking the program
- connfigureが見付けることができないライブラリをリ
ンクするには、LDADDを使う。LDADDはリンカのオプショ
ンを格納するところではない。その目的には、
AM_LDFLAGSを使う。
- ビルトするプログラムが複数ある場合、LDADDは全て
のプログラムに対して適用される。
- prog_LDADDにて、progというプログラムについて上書
きできる。prog_LDADDには'-l', '-L', '-dlopen',
'-dlpreopen'を使うことができる。それ以外のオプ
ションはprog_LDFLAGに書くべき。
- 自身のパッケージの中でbuildするライブラリは、
prog_LDADDにて'-l'オプションで取り扱うべきではな
い。明示的にファイル名やパスを書くべきだ。サー
ドバーティのライブラリは'-l'でよい。
- う、prog_DEPENDENCIESのところの説明がいまひとつ
わからない。そもそもリンカの知識がないからだ。
**** 8.1.3 Conditional compilation of sources
- ビルドに使うソースを設定に従って変更する方法に
ついて。
- _SOURCESの値にconfigure substitutionを使うこと
はできない。たとえば、AC_SUBSTで定義したFOOにつ
いて、@FOO@や$(FOO)で参照すること。
- 2つの方法がある。
***** 8.1.3.1 Conditional compilcation using '_LDADD' substitution
- こんな感じ。
- Makefile.am
bin_PROGRAMS = hello
hello_SOURCES = hello-common.c
EXTRA_hello_SOURCES = hello-linux.c hello-generic.c
hello_LDADD = $(HELLO_SYSTEM)
hello_DEPENDENCIES = $(HELLO_SYSTEM)
- configure.ac
...
case $host in
*linux*) HELLO_SYSTEM='hello-linux.$(OBJEXT)' ;;
*) HELLO_SYSTEM='hello-generic.$(OBJEXT)' ;;
esac
AC_SUBST([HELLO_SYSTEM])
...
***** 8.1.3.2 Conditional compilation using Automake conditionals
- こんな感じ。
- Makefile.am
bin_PROGRAMS = hello
if LINUX
hello_SOURCES = hello-linux.c hello-common.c
else
hello_SOURCES = hello-generic.c hello-common.c
endif
- configure.ac
AM_CONDITIONALをつかってLINUXを定義する。
**** 8.1.4 Conditional compilation of programs
- ビルド対象であるプログラムを設定に従って変更する
方法について。
***** 8.1.4.1 Conditional programs using `configure' substitutions
- うーん。よくわからない。Autoconfを理解していな
いからだろう。
***** 8.1.4.2 Conditional programs using Automake conditionals
- これはわかりやすい。
bin_PROGRAMS = cpio pax
if WANT_MT
bin_PROGRAMS += mt
endif
if WANT_RMT
libexec_PROGRAMS = rmt
endif
*** 8.2 Building a library
- ライブラリをビルドするのは、プログラムをビルド
するのとおおよそ一緒。
- primaryは'LIBRARIES'である。
- _SOURCESの考え方はPROGRAMSと同じ。ただし、ライ
ブラリ名は正準化されるので、たとえば、libcpio.a
については、libcpio_a_SOURCESとなる。
- LDADDで指定すると静的リンクができる。例。
noinst_LIBRARIES = libcpio.a
libcpio_a_SOURCES = ...
bin_PROGRAMS = cpio
cpio_SOURCES = cpio.c ...
cpio_LDADD = libcpio.a
*** 8.3 Building a Shared Libraly
- Libtoolsは教材の方で理解すべしということで割愛。
**** 8.3.1 The Libtool Concept
**** 8.3.2 Building Libtool Libraries
**** 8.3.3 Building Libtool Libraries Conditionally
**** 8.3.4 Libtool Libraries with Conditional Sources
**** 8.3.5 Libtool Convenience Libraries
**** 8.3.6 Libtool Modules
**** 8.3.7 _LIBADD, _LDFLAGS, and _LIBTOOLFLAGS
**** 8.3.8 LTLIBOBJS and LTALLOCA
**** 8.3.9 Common Issues Related to Libtool's Use
***** 8.3.9.1 Error: 'required file' ./ltmain.sh' not found'
***** 8.3.9.2 Objects 'created with both libtool and without'
*** 8.4 Program and Library Variables
- プログラム(名)やライブラリ(名)に紐づいた変数の一
覧。
- 'maude'のところは正準プログラム名または正準ライ
ブラリ名となる。
`maude_SOURCES'
`EXTRA_maude_SOURCES'
`maude_AR'
`maude_LIBADD'
`maude_LDADD'
`maude_LDFLAGS'
`maude_LIBTOOLFLAGS'
`maude_DEPENDENCIES'
`maude_LINK'
`maude_CCASFLAGS'
`maude_CFLAGS'
`maude_CPPFLAGS'
`maude_CXXFLAGS'
`maude_FFLAGS'
`maude_GCJFLAGS'
`maude_LFLAGS'
`maude_OBJCFLAGS'
`maude_RFLAGS'
`maude_UPCFLAGS'
`maude_YFLAGS'
`maude_SHORTNAME'
*** 8.5 Default _SOURCES
- _SOURCESのデフォルト設定の様子。
*** 8.6 Special handling for LIBOBJS and ALLOCA
- わからない。。。
*** 8.7 Variables used when building a program
- AutomakeがつくったMakefileの中で使われている変
数の紹介。
- Autoconf 由来
`CC', `CFLAGS', `CPPFLAGS', `DEFS', `LDFLAGS', and `LIBS'
- Automake 作成
`AM_CPPFLAGS', `INCLUDES', `AM_CFLAGS',
`COMPILE', `AM_LDFLAGS', and `LINK'
*** 8.8 Yacc and Lex support
- Automakeは、yaccやlexの中間ファイルはソースと同
じであるとする。
foo.y -> foo.c -> foo.o
伝統的には、y.tab.cなところ。
- 拡張子によって生成されるソースの種類がかわる。
.y -> .c
.yy -> .cc
.y++ -> .c++
.yxx -> .cxx
.ypp -> .cpp
- lexの拡張子についても同様。
- 中間ファイルはSOURCESに列記してはいけない。yacc
or lex のソースだけ示すこと。
- 中間ファイルは配布物に含まれる。ユーザがyaccや
lexをもっていないかもしれないから。
- configure.acには`AC_PROG_YACC'マクロを書く。こ
れが'YACC'変数を設定する。
- 'yacc'が起動されるとき、'YFLAGS'と'AM_YFLAGS'と
をオプションとして渡される。前者はユーザ向け後
者はメンテナ向け。
- 'AM_YFLAGS'は'-d'オブションを指定するために使わ
れる。('-d'はヘッダファイルも生成するというオプ
ション) Automakeはこのオプションがあるとき、そ
のヘッダファイルのルールを適切に設定する。
- ただし、そのヘッダがどこで使われるかはメンテナ
次第であるからメンテナが自分で設定する。通常、
BUILT_SOURCESEに書いて、他のビルドが始まる前に
存在するようにする。例。
BUILT_SOURCES = parser.h
AM_YFLAGS = -d
bin_PROGRAMS = foo
foo_SOURCES = ... parser.y ...
- 続いてlex。
- configure.acには、AC_PROG_LEX。
- LFLAGSとAM_FLAGS、あります。
- もし、AM_MAINTAINER_MODEが使われているなら、
maitainer-modeがオンのときだけ、yaccやlexのため
のリビルドルールは有効になる。(ファイルを削除し
たときは当然有効になるが)
- lexまたはyaccのソースがあるときは、'automake
-i'は自動的に'ylwrap'というプログラムをインストー
ルする。これは、yacc自体の出力ファイル名が固定な
ので、それを回避するためのラッパ。
- なおyaccの出力は、常に同じシンボルを使うため、2
つのyacc生成パーサをひとつの実行ファイルにリン
クすることはできない。
- それを回避するためのrenaming hack。
#define yymaxdepth c_maxdepth
#define yyparse c_parse
#define yylex c_lex
#define yyerror c_error
#define yylval c_lval
#define yychar c_char
#define yydebug c_debug
#define yypact c_pact
#define yyr1 c_r1
#define yyr2 c_r2
#define yydef c_def
#define yychk c_chk
#define yypgo c_pgo
#define yyact c_act
#define yyexca c_exca
#define yyerrflag c_errflag
#define yynerrs c_nerrs
#define yyps c_ps
#define yypv c_pv
#define yys c_s
#define yy_yys c_yys
#define yystate c_state
#define yytmp c_tmp
#define yyv c_v
#define yy_yyv c_yyv
#define yyval c_val
#define yylloc c_lloc
#define yyreds c_reds
#define yytoks c_toks
#define yylhs c_yylhs
#define yylen c_yylen
#define yydefred c_yydefred
#define yydgoto c_yydgoto
#define yysindex c_yysindex
#define yyrindex c_yyrindex
#define yygindex c_yygindex
#define yytable c_yytable
#define yycheck c_yycheck
#define yyname c_yyname
#define yyrule c_yyrule
- このC_の部分をいろいろ変える。
*** 8.9 C++ Support
- 短い。割愛。
*** 8.10 Objective C Support
- 短い。割愛。
*** 8.11 Unified Parallel C Support
- 短い。割愛。
*** 8.12 Assembly Support
- 短い。割愛。
*** 8.13 Fortram 77 Support
- 割愛。
**** 8.13.1 Preprocessing Fortran 77
**** 8.13.2 Compiling Fortran 77 Files
**** 8.13.3 Mixing Fortran 77 With C and C++
***** 8.13.3.1 How the Linker is Chosen
*** 8.14 Fortran 9x Support
- 短い。割愛。
**** 8.14.1 Compiling Fortran 9x Files
*** 8.15 Java Support
- 短い。割愛。
*** 8.16 Vala Support
- 短い。割愛。
*** 8.17 Support for Other Languages
- このマニュアルに載っている言語以外は対応してい
ないと考えてよい。
*** 8.18 Automatic de-ANSI-fication
- この節の内容は旧式。使うべきはない。
- k & r cから ansi cへの移行期に、ansiで書いたソー
スをk & r cに変換する機能としてできた。
*** 8.19 Automatic dependency tracking
- Automakeのモデルは、依存関係の解析はビルド時に
行う、というもの。
- これを実現するために、すべてのコンパイルはラッ
パプログラムdepcomp経由で実行される。
- depcompは、各種多様なコンパイラそれぞれに対して
どのような形式で依存関係情報を記述すべきかを熟
知している。
*** 8.20 Support for executable extensions
- '.exe'の取扱い。割愛。
こつこつ。
0 件のコメント:
コメントを投稿