nDiki : GNU Make

GNU Make

GNU 版 make ユーティリティ。

GNU Coding Standards で求められているターゲット

GNU Coding Standards 7.2.5 Standard Targets for Users より

  • all
  • install
  • install-html
  • install-dvi
  • install-pdf
  • install-ps
  • uninstall
  • install-strip
  • clean
  • distclean
  • mostlyclean
  • maintainer-clean
  • TAGS
  • info
  • dvi
  • html
  • pdf
  • ps
  • dist
  • check
  • installcheck
  • installdirs

Win32GNU Make

MinGW のものが使える。

mingw32-make-3.80.0-3.tar.gz の中に bin/mingw32-make.exe あり。

Win32 で標準的なコマンドがない時の代替

Perl が使えることを前提とすれば ExtUtils::Command を使うことで、UNIX / Windows どちらでも動くコマンドを定義できる。

 RM_RF  = perl -MExtUtils::Command -e rm_rf
 CP     = perl -MExtUtils::Command -e cp
 MKPATH = perl -MExtUtils::Command -e mkpath

関連情報

Windows 関連

他のビルドツール

  • makepp
    • Perlで書かれた make の改良版。
  • PBS
    • pure perl
  • Rake
  • Ant
  • NAnt
  • SCons
  • NAnt
  • Jam
  • Cook
  • jmk
  • Odin
  • smake
  • tmake
  • qmake
  • CMake
    • クロスプラットフォーム Makefile ジェネレータ
    • VTK などで使用
  • MSBuild

スポンサード リンク

2004年7月23日 (金)

プロジェクト関連ドキュメントを TeX

現在進行中のプロジェクトの一つがそろそろ大詰め。 ドキュメント書きに突入。 前回までは過去の方法を踏襲して MS Word ベースだったのだが、自分がマネージャになった今期からは全面的に TeX ベースへ移行させる。

LinuxWindows でそれぞれ

を用意。 Makefile は時間がなかったので GNUmakefile と Makefile を作って Linux 用と Windows 用の両方作ったのだが、後々面倒なので一本化したい。

スポンサード リンク
[ 7月23日全て ]

2004年7月24日 (土)

WindowsGNU Make

Windows だと nmake がやっぱり主流だろうか。 しかし GNU Make とは違う点が多く、使い分けるのも面倒。 かといって Ant というのも面倒。

ということで気軽に使える Windows 用の GNU Make を探す。 Cygwin 版は共同作業者に入れてもらうのが面倒なので却下(Makefile から呼ばれるコマンド群もLinuxと同様のものが入るのでこちらの方が便利といえば便利ではあるのだが)。

MinGW版が 3.80 をポーティングしているし単体でも動きそうなのでこれを試してみることにする。

mingw32-make-3.80.0-3.exe を取ってきて実行。make そのものだと思っていたがマニュアル等を含むインストーラだった。 一旦インストールして、mingw32-make.exe をコピーしてアンインストール。 mingw32-make.exe 単体で動作するので取り扱いが楽でよい(必要なら make.exe にでもリネーム)。

Windows 特有の問題があるかどうかは今後使ってみてチェックだな。

[ 7月24日全て ]

2004年8月5日 (木)

WindowsGNU tar

この間 Windows 用の GNU Make として MinGW版を選択して、プロジェクトのドキュメントのビルドの自動化をすすめている。

しかし(最初からわかっていたのだが)make だけでは駄目で各ユーティリティがなくて結構不便。 touch すら無いし。 幸い全員の環境に ActivePerl が入っていることが前提になっているので、必要ならスクリプトを書いていけばある程度はなんとかなる。

今日は、プロジェクトで開発したPerl モジュールのソースアーカイブを自動的に一時ディレクトリに展開して pod2latex をかけてごにょごにょという処理の Makefile を書く。 さすがに tar が無いと無理だ (Archive::Tar を使うという手もなくはないが結局標準ではないし)。

GnuWin32

ということでGNU tarを探す。例によってインストール不要という条件で。

MinGW の中からは探せず。 GnuWin32 のものを使ってみる。 ついでに gzip

  • tar.exe (GNU tar tar-1.13-1-bin.zip)
    • libiconv-2.dll (libiconv-1.8-1-bin.zip)
    • libintl-2.dll (libintl-0.11.5-2-bin.zip)
  • gzip.exe (gzip-1.3.5-bin.zip)

fork できないとかで tar の -z オプションが使えない。かなりがっかり。

texinst753 (W32TeX Web2C-7.5.3 簡易インストーラ)

あれ、gzip が最初からPATH上にあるなと思ったら、texinst753 に含まれていた奴。 GNU tar も入っている。 ちょっとバージョンが古めだけど -z も効くし、これが扱いやすいかも。

なにより他のプロジェクトメンバの Windows BOX にもそれぞれ入っているはずだし。

ということで GNU tar 確保。

[ 8月5日全て ]

2005年4月20日 (水)

SConsGNU Autotools のかわりになるか

NSIS のサイトによるとビルドに「SCons」を使うようしたらしい。

  • クロスプラットフォーム
  • AutoconfAutomake と同様の機能を統合
  • LaTeX もビルトインサポート

と興味深いツールになっているようだ。

現在プロジェクトLaTeXベースのドキュメント生成には GNU Make を使っているのだが、UNIXWindows の両方でビルドできるようにするには ComSpec 環境変数の有無で使用するコマンドを切り換えたり等いろいろ面倒なので、代替ツールとして使えないかなと。

基本的な機能は Make に対する改良がなされているようであるし、コピー等ファイル操作も SCons 自体がもっているのでクロスプラットフォームでビルドできるようにするのも楽そうだ。

一方 Autoconf 系の機能については、インストール済みのライブラリの検出や実装レベルのチェック等を実装しているようである。 make check や make dist、make install 等にあたるターゲットに関する機能(あるいは規約)のようなものは無い。これは非常に残念。 結局自分が Ant を使わなくなったのも GNU Autotools にあるこれらの機能に欠けているからであるし。

実は私がPerl が好きな理由の一つとして、これらサポートが充実しているという点がある。Perl では ExtUtils::MakeMaker (あるいは Module::Build)があり、ビルドからテスト、ソースパッケージのパッケージングまでフレームワークが整っている。

SConsPython ベースで、Makefile にあたるファイルも Python スクリプトである。 SCons が影響を受けた Cons は Perl ベースであったのだが、既に2001年5月ごろから開発が止まってしまっている。残念。

ということで Make の代替には使えそうであるが、GNU Autotools と同じようなことをするにはいろいろ手をかけないといけないといった印象。

[ 4月20日全て ]

2005年4月29日 (金)

SCons 微妙

SConspLaTeX2e ソースファイルを PDF に変換する SConstruct ファイルを書いてみた。

 bb_builder = Builder(action = 'ebb $SOURCE',
                      suffix = '.bb', src_suffix = '.png')
 pdf_builder = Builder(action = 'dvipdfmx -V 4 $SOURCE',
                       suffix = 'pdf', src_suffix = '.dvi')
 env = Environment(LATEX = 'platex')
 env.Append(BUILDERS = {'BBBuilder' : bb_builder})
 env.Append(BUILDERS = {'PDFBuilder' : pdf_builder})
 env.PDFBuilder(target = 'example-doc')
 env.DVI(target = 'example-doc', source = 'example-doc.tex')
 env.Clean('example-doc.dvi',
           ['example-doc.log', 'example-doc.out',
            'example-doc.toc', 'example-doc.aux'])
 env.Depends('example-doc.dvi', 'image1.bb')
 env.Depends('example-doc.dvi', 'image2.bb')
 env.Depends('example-doc.dvi', 'image3.bb')
 env.BBBuilder('image1')
 env.BBBuilder('image2')
 env.BBBuilder('image3')
  • 組み込みの PDF builder が今いち挙動がよくわからないので Builder を作成
  • .bb ファイル用の Builder を作成
  • latex ではなく platex を使うように

.tex から .dvi の生成ルールでは、補助ファイルを見て適宜数回 platex を実行してくれる。ここら辺はさすが。

GNU Make のような暗黙のルールの適用がない(わからない)ので、.bb ファイルを dvi の依存ファイルに指定するだけでは駄目で、ビルド指定をする必要があるのがちょっと面倒。

これだけだと GNU Make より便利とはいえないな。 プラットフォームによって異なるコマンド(cp / copy など)を使うような事や、もうちょっと複雑な事などをしないとそれほどメリットがでないか。

[ 4月29日全て ]

2005年8月24日 (水)

Module::Buildソースパッケージング

ExtUtils::MakeMaker

私が Perl が好きな理由の一つに、標準でExtUtils::MakeMakerという Makefile ジェネレータがついているところである。これを使って Makefile.PL を書くと

 perl Makefile.PL
 make manifest
 make
 make test
 make dist

で <pacakge>-<versionno>.tar.gz というソースパッケージを作ることができ、

 tar zxvf <pacakge>-<versionno>.tar.gz
 cd <pacakge>-<versionno>
 perl Makefile.PL
 make
 make test
 make install

という手順でインストールする事ができるようになる。 パッケージの作り方が確立されているので、容易に新しいパッケージを開発しはじめられる。

逆に Java でプログラムを書くのが億劫なのは、このあたりの準備が面倒だからである。 Ant を使っても結局ここら辺自分でやらなければならないし。

ちょっとしたアーカイブの作成

ちょっとしたパッケージを作りたいと思うことは良くある。 例えばいくつかのデータファイルと、READMEファイルなんかをひとまとめにしてアーカイブにするとか。

本当にちょっとしたであれば、手動でアーカイブすれば良いのだが、

  • アーカイブしたいファイル群がバージョン管理下にあって、CVS ディレクトリや .svn ディレクトリがある (除外してアーカイブする必要がある)
  • 同じディレクトリにある、作業用のファイルはアーカイブしたくない (除外してアーカイブする必要がある)
  • アーカイブする前に、チェック用のリグレッションテスト一式を走らせたい (リグレッションテストをかけられるようにする)
  • UNIX でも Windows でもアーカイブ化できるようにしたい。

あたりを考慮しなければならない時は面倒くさくなってくる。

自動化としては

あたりがぱっと思い浮かぶ。 しかし、最初の2つは毎回同じようなものを書くのが面倒だし保守もしにくい。 GNU Autotools はちょっとごっつすぎだし、Windows での環境構築も面倒。

ExtUtils::MakeMaker の欠点

ということで最初は ExtUtils::MakeMaker を使うという線で考えてみた。 もともと Perl モジュール用で汎用用途にはちょっと邪魔な振舞いもあるが、使えないことはないと思う。 しかし make (GNU Make あるいは nmake など) に依存しているという欠点がある。

Module::Build

ということで ExtUtils::MakeMaker の代替である Module::Build ベースで汎用用途に使えないか検討してみた。こちらは pure Perl で make を必要としない。

Module::BuildPerl モジュールビルドにあわせた振舞いがあるものの、ちょっとカスタマイズすれば使えそうだ。 で、いろいろいじった結果、次のような感じにすると使いやすそうだ。

 use Module::Build;
 my $class = Module::Build
   ->subclass(class => 'NonmoduleBuilder',
              code => q{
                        # Don't make blib
                        sub ACTION_code {};
                        # Don't make blib
                        sub ACTION_docs {};
                        # Don't make META.yml
                        sub ACTION_distmeta {
                          # no warning on ACTION_distdir
                          $_[0]->{metafile} = 'MANIFEST';
                        };
                        # Don't add MEATA.yml to MANIFEST
                        sub ACTION_manifest {
                          $_[0]->{metafile} = 'MANIFEST',
                          $_[0]->SUPER::ACTION_manifest(@_);
                        };
                       });

 # Set your archive name and version.
 $class->new(dist_name => 'mypackage',
             dist_version => '1.0.2',
             )->create_build_script;

カスタマイズした部分は以下(Module::Build 0.26 で動作確認)。

  • Perl モジュールビルドに特有の blib ディレクトリを作らないようにする。
  • META.yml を生成しないようにし、アーカイブに含まれないようにする。

上記のようなファイルを Build.PL という名前で作っておけば

 perl Build.PL
 ./Build manifest
 ./Build
 ./Build test
 ./Build dist

等として、アーカイブ作成が容易にできるようになる。

しばらくこの方法でいろいろ試してみることにしてみよう。

[ 8月24日全て ]

2007年10月18日 (木)

今日のさえずり - 最近 CM で「しりあがり寿」の名を見る。うちでは画伯扱い(ほぼ日手帳の影響)。

  • 10:17 プロジェクトのスケジュール共有用に Google カレンダー上に、1つカレンダーを新規作成。 *Tw*
  • 10:50 GNU Make (Win32) では変数を設定しても、そのままではコマンド実行時の環境変数には入らないことを思い出した。 *Tw*
  • 11:57 最近 CM で「しりあがり寿」の名を見る。うちでは画伯扱い(ほぼ日手帳の影響)。 *Tw*
  • 12:32 着もと化した。 *Tw*
[ 10月18日全て ]

2010年9月9日 (木)

今日のさえずり: パスワードを暗記しておくのに何バイト消費しているのだろう

2010年09月09日

[ 9月9日全て ]

2010年9月14日 (火)

今日のさえずり: テレビは代々2画面機能付きにしてる

2010年09月14日

  • 08:29 @yakifumi REGZA 使い勝手どうですか? HDD 録画って活用してます?
  • 09:38 ポケットティシュー配りの恩恵にあずかれるのって大都市圏だけなのかな、やっぱり。地方だと自腹で買うの? 義母が段ボール箱の隙間に入れて送ってくれる。
  • 09:49 外人がガンの T シャツ着ててハッとした。
  • 09:50 日本人がギャンの T シャツ着ててハッとした。
  • 09:51 (後者はフィクション)
  • 10:10 久しぶりに問題解決シートを使おう。
  • 12:49 親子丼 490円。 (@ なか卯 神田佐久間町店) http://4sq.com/9tdwTs
  • 13:04 REGZA 37ZS1ヨドバシカメラで見てきた。148,900円はまだちょっと高いなあ。他の37V型 REGZA は11万円台だったので、この差は大きい。 http://amzn.to/cwe4lQ
  • 13:12 149,800円だった。 RT @Naney: REGZA 37ZS1ヨドバシカメラで見てきた。148,900円はまだちょっと高いなあ。他の37V型 REGZA は11万円台だったので、この差は大きい。 http://amzn.to/cwe4lQ
  • 15:10 頂きます。 RT @as_tone: 業務連絡:クッキーが早くもしけってきているので早く食べて下さい。
  • 15:11 環境変数 ComSpec っていつから comspec になったんだよう。 GNU Make の ifdef ComSpec が正しく動作していないのに気がつくのに結構かかってしまったよ……。
  • 18:39 operational transformation (OT) って実装難易度高いのかな。
  • 19:06 @yakifumi おお、そうですか。やっぱり REGZA にしようかなあ。今日見てきたんですが最新モデルはまだちょっと高かったので年内もう少し様子を見たいところではあります。
  • 21:24 REGZA 37ZS1 はまだ割高なので 37Z1 の方がいいかなあ。機能はほぼ ZS1 と同じだし。 http://amzn.to/dgSKSr
  • 21:49 今のテレビ (KV-28DX750) にメジャーあててみた。37V型にすると一回り大きくなる格好。まずまずかな。
  • 23:21 テレビは代々2画面機能付きにしてる。使うの年に数回だけど。
[ 9月14日全て ]

2013年10月10日 (木)

今日のさえずり: 新しく開発しているアレ、勘定奉行的な名前に変更されました

2013年10月10日

[ 10月10日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・プロダクトオーナーをしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

follow us in feedly

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.542055s / load averages: 2.69, 2.04, 1.34
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker