目次: Linux
ソースコードのビルドシステムは多々あって決定打はない(個人的にはそう思う)のですが、比較的メジャーと言って良いのがGNU autotoolsです。ビルドする際にconfigureしてmakeするヤツは、大抵autotoolsが絡んでいます。
そんなGNU autotoolsを成すツール群の一つにautoconf/automakeと言うツールがあります。こいつらは簡単に言えばMakefileを作るツールです。
configure.ac --(autoconf)--> configure Makefile.am --(automake)--> Makefile.in --(configure)--> Makefile
最終的に生成されるのはMakefileなのに、なぜ直接書かず遠回りをするかというと、どんな環境でもそれなりに動くMakefileを直接書くのは、実は結構大変だからです。
例えば、依存関係にあるライブラリの有無をチェックしつつ、クロスコンパイルで動的ライブラリを生成するようなMakefileをパッと書けますか?私には無理そうですし、仮に書けたとしても、Makefileを作るのは手段であって目的ではないので、あまり時間を使いたくありません。
ビルドでお決まりの手順はツールで自動生成して楽して作りたい、これがGNU autotoolsや他のビルドツールを使う目的です。
こんな便利なautomakeですが、たまに仕様が変わって、以前の書き方だと怒られることがあります。
楽するためにツールを使っていたのに、ツールの仕様変更に対応するため時間を使うのは本末転倒な感じもしますが、それでもMakefileを直接書くより断然楽でしょうね。
昔のバージョンであるautomake-1.9ではこういう書き方が出来たのですが、
COMMON_DIR = ./common
common_SOURCES = $(COMMON_DIR)/utils.c
これがautomake-1.14だと、
test/Makefile.am:19: warning: source file '$(COMMON_DIR)/utils.c' is in a subdirectory, test/Makefile.am:19: but option 'subdir-objects' is disabled automake: warning: possible forward-incompatibility. automake: At least a source file is in a subdirectory, but the 'subdir-objects' automake: automake option hasn't been enabled. For now, the corresponding output automake: object file(s) will be placed in the top-level directory. However, automake: this behaviour will change in future Automake versions: they will automake: unconditionally cause object files to be placed in the same subdirectory automake: of the corresponding sources. automake: You are advised to start using 'subdir-objects' option throughout your automake: project, to avoid future incompatibilities.
こんな風に長々と説教されます。警告の通りsubdir-objectsを有効にすると、今度は $(COMMON_DIR) という名前のディレクトリが作られ、common/utils.cは無いと言われ、コンパイルエラーになります。
なんじゃそりゃ。
この警告を解決する方法は、サブディレクトリにもMakefile.amを置くこと、のようです。
$ tree
.
|-- Makefile.am
|-- configure.ac
`-- test
|-- Makefile.am
|-- common
| `-- utils.c
`-- test.c
----
configure.ac
----
AC_PREREQ(2.61)
AC_INIT([automake_test], [0.1])
AC_ARG_PROGRAM()
AC_CONFIG_SRCDIR([test/test.c])
AC_CONFIG_HEADER([config.h])
AC_CONFIG_AUX_DIR([conf])
AM_INIT_AUTOMAKE([foreign])
LT_INIT()
AC_CONFIG_FILES([Makefile
test/Makefile])
AC_OUTPUT()
----
Makefile.am
----
SUBDIRS = test
----
test/Makefile.am
----
testdir = $(libdir)
test_LTLIBRARIES = libtest.la
libtest_la_SOURCES = test.c \
common/utils.c
このようなプロジェクトがあったとします。このプロジェクトはautomakeに、下記のように怒られます。
$ autoreconf --force test/Makefile.am:5: warning: source file 'common/utils.c' is in a subdirectory, test/Makefile.am:5: but option 'subdir-objects' is disabled automake: warning: possible forward-incompatibility. automake: At least a source file is in a subdirectory, but the 'subdir-objects' automake: automake option hasn't been enabled. For now, the corresponding output automake: object file(s) will be placed in the top-level directory. However, automake: this behaviour will change in future Automake versions: they will automake: unconditionally cause object files to be placed in the same subdirectory automake: of the corresponding sources. automake: You are advised to start using 'subdir-objects' option throughout your automake: project, to avoid future incompatibilities. autoreconf2.50: automake failed with exit status: 1
以下のように各ディレクトリにMakefile.amを作ってあげれば、警告は出なくなります。
.
|-- Makefile.am
|-- configure.ac★変更★
`-- test
|-- Makefile.am★変更★
|-- common
| |-- Makefile.am★追加★
| `-- utils.c
`-- test.c
----
configure.ac
----
AC_PREREQ(2.61)
AC_INIT([automake_test], [0.1])
AC_ARG_PROGRAM()
AC_CONFIG_SRCDIR([test/test.c])
AC_CONFIG_HEADER([config.h])
AC_CONFIG_AUX_DIR([conf])
AM_INIT_AUTOMAKE([foreign])
LT_INIT()
AC_CONFIG_FILES([Makefile
test/Makefile test/common/Makefile])
^^^^^^^^^^^^^^^^^^^^ 追加
AC_OUTPUT()
----
test/Makefile.am
----
SUBDIRS = common
test_newdir = $(libdir)
test_new_LTLIBRARIES = libtest_new.la
libtest_new_la_SOURCES = test.c
libtest_new_la_LIBADD = common/libcommon.la
----
test/common/Makefile.am
----
noinst_LTLIBRARIES = libcommon.la
libcommon_la_SOURCES = utils.c
最初は面倒くさいですが、やってみるとtestとtest/commonが分離されて見通しが良くなります。
従来の方法(親ディレクトリにMakefile.amを置く方法)と、新しい方法(各ディレクトリにMakefile.amを置く方法)の利点と欠点を考えてみます。
利点は、再利用性が高くなることです。
先の例で出てきたcommonディレクトリが「何らかの便利な機能を提供しているパッケージ」だとして、他のプロジェクトにcommonのコードを流用する場合を考えてみましょう。
従来のtest/Makefile.amに全て書く方法だと、commonディレクトリのソースコードは使いまわせますが、ビルド設定であるMakefile.amが親ディレクトリのtest側にあって、単純に使いまわせません。なぜならtest/Makefile.amではtestのビルド設定とcommonのビルド設定が混ざって書かれているため、commonのビルド設定だけを抽出するのが難しいためです。
これが新しいtest/Makefile.amとtest/common/Makefile.amに分ける方法だと、文字通りcommonディレクトリをコピーするだけでMakefile.amつまりビルドの設定も使いまわすことができます。
欠点は面倒くさいことです。
無意味にディレクトリを分割したがる輩には、ディレクトリごとにMakefile.amを作らなければならない面倒くささが、ある意味の抑止力になるので、欠点だとも言い切れませんが、やはり面倒くさいものは面倒くさいです…。
ちなみに従来の方法で書くと警告が出ますが、今のところ使えない訳でもない(※)ので、ちょっと試してみるだけとか、一時的なツールに使うだけであれば、従来の方法を選べば良いと思います。
(※)今は警告だけですが、そのうち廃止されるかもしれません。
この記事にコメントする
会社で大幅にソフトを置き換えるチャンスがあったので、思い切ってCからC++11(gcc-4.6で使える範囲だけ)に切り替えました。
まだまだ使いこなせてませんがC++98より見やすいです。それでもC++ は魔界だなーと思うこともありますけど…。
Effective Modern C++ にも出てますが、C++11で導入されたuniform initialization(波括弧 { a, b, c, } での初期化)は、丸括弧や等号を置き換えることができます。大抵の場合は、ですが。
コンテナ系などstd::initializer_listを引数に取れる場合は、丸括弧と置き換えると動きが変わってしまいます。
int i1(5);
-> 5
int i2{5};
-> 5
std::vector<int> b1(5);
-> size:5: 0, 0, 0, 0, 0,
std::vector<int> b2{5};
-> size:1: 5,
丸括弧は丸括弧で、引数が0個になるといきなり関数宣言扱いされる、クラスメンバ変数に使えないなど、一貫性がなくて使いづらいのです。
std::vector<int> a1();
-> a1 type is std::vector<int, std::allocator<int> > ()
std::vector<int> a2{};
-> size:0:
結局、コンストラクタがstd::initializer_listを取れるかどうかを意識して、丸括弧と波括弧を使い分ける必要がありまして、だいぶ難しいですね…。
メモ: 技術系の話はFacebookから転記しておくことにした。
この記事にコメントする
車を放置しすぎてバッテリーが上がり、今まで自宅に3回ほどJAFを呼んでいます。4回だったかもしれないが…。
あまりにも車が可哀想なので、1か月に1度はドライブに行くことにしました。今回は高槻市の北側を体験するコースです。
距離は30km程度、約1時間ほどです。ここまで書いておいてなんですが、あまりオススメしません。
46号線から一瞬だけ見える高槻市、茨木市の夜景は綺麗ですが、他は森ばかりで何も見えません。733号線は対向可能なのに車1台分しか幅がなく、横は崖で、二度と行きたくない道です。
もっとマシな道はねーのかよ?と思うのですが、高槻市は道路状況があまり良くないのです。
北は山道、南は淀川で通れず、東西は大阪〜京都を移動する車で渋滞だらけです。
その点言うと、つくば市は、土地が平らで、道が綺麗で、空いてて、広くて、とても良かったんですがねえ…。
この記事にコメントする
| < | 2015 | > | ||||
| << | < | 12 | > | >> | ||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| - | - | 1 | 2 | 3 | 4 | 5 |
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 | - | - |
25年10月15日
25年10月18日
22年5月5日
25年10月19日
23年4月11日
06年4月22日
25年10月17日
25年10月6日
25年10月13日
20年10月23日
25年10月12日
20年8月29日
19年1月13日
18年10月13日
18年9月3日
18年8月20日
18年7月23日
18年7月22日
18年10月14日
18年11月10日
wiki
Linux JM
Java API
2002年
2003年
2004年
2005年
2006年
2007年
2008年
2009年
2010年
2011年
2012年
2013年
2014年
2015年
2016年
2017年
2018年
2019年
2020年
2021年
2022年
2023年
2024年
2025年
過去日記について
アクセス統計
サーバ一覧
サイトの情報合計:
本日: