間が空きましたが、 git の運用指針 - Life like a clown のフォロー記事、第 2 弾。

公開リポジトリに push した commit を rebase してはいけない

rebase に関しては、まだ使いどころが今一つ掴めないでいるのですが、明快な指針が一つ示されていました。

あぁ、このすばらしいリベース機能。しかし、残念ながら欠点もあります。その欠点はほんの一行でまとめることができます。

公開リポジトリにプッシュしたコミットをリベースしてはいけない

この指針に従っている限り、すべてはうまく進みます。もしこれを守らなければ、あなたは嫌われ者となり、友人や家族からも軽蔑されることになるでしょう。

Git - リベース

なぜ、公開リポジトリに push した commit に対して、後から rebase を行ってはいけないのかと言うと、「（rebase で作られた commit は元の commit と同内容でも別の commit となるため）rebase してしまうと push できなくなる」と言う理由のようです。何故、push できなくなってしまうのかについては こわくない Git と言うスライドで分かりやすく解説されていますので、このスライドの 104 〜 146 枚目を何度か追うと理解できると思います。

逆に、公開リポジトリに push する前であれば rebase を使って統合ブランチに追従するのは問題ないようです。http://www.amazon.co.jp/exec/obidos/ASIN/4798023809/cielquis-blog-22/ref=nosim/:title=入門 Git] では、rebase 等を使用して自分の修正履歴を綺麗に整理して公開できる事も git のメリットの一つとして挙げられていました。

しかし、git では、個人の作業リポジトリがあるために、共用リポジトリに push して他のメンバーに結果を見せるまでは、今まで見てきたように rebase したり commit --amend したり reset --hard したり等の方法で歴史を訂正することができます。従来の集中型のシステムと異なり、間違いや失敗をおそれずに、自分の作業の都合だけで区切りの良い時点でコミットして行くことができ、また、自分の作ってきた歴史を綺麗に整理し直して見やすくしてから他人に自分の仕事の結果を見せることができるのが、大きな利点です。

※強調はブログ筆者によるもの

入門 Git - Chapter 6. グループで使う（p.93）

rebase の使いどころ

さて、rebase の使いどころに関してですが、rebaseはコミットグラフを綺麗にするためじゃなくてffマージをするためにあるのであった と言う記事がありました。この記事自体は「FastForward マージの利点」に主眼が置かれて書かれているので直接的には関係ないのですが、そう言った FastForward マージの恩恵にあやかるために rebase が存在しているのかな、と言う気がします。また、Git - リベース での解説においても FastForward できるようにする事を念頭に rebase を実行している感が見て取れます。

一方で、 git merge に関するメモ - Life like a clown でも書いたように、現在の git の運用においては「基本的に Non-FastForward でマージする」と言う方法が割とポピュラーになっているようなので、そう言った意味でも rebase を使うタイミングと言うのは、感覚的になかなか掴めないでいます。

入門 Git では、多人数で開発を行う場合の「トピックブランチからメインブランチへの統合作業」に際して、rebase に関する検討が記載されていました。

プロジェクトによっては、バージョン管理方針として、新しい変更が常に最新の状態から始まっていることを要求するものもあります（例えば X.org プロジェクトは最初に git を取り入れた頃からそのような方針を取っています）。

このような場合には、完成したブランチをまとめる前に、もう 1 ステップ、トピックブランチでした仕事の歴史のクリーンアップが必要になります。

…（中略）…

一般的に言って、プロジェクト全体で新しい変更が必ず最新状態の上にリベースされていることを要求するのはプロジェクトメンバーにとって不要な負担を強いることになり、また、トピックをリベースする時に競合解決を間違った場合に、どこにもそのトピックの正しく動くバージョンが残っていないという状況を引き起こすことになるので、メリットはあまりありません。

しかしながら、プロジェクト内でのメンバーの役割分担がきちんと行われていれば、完成したトピックが、そのトピックを開発中に共用リポジトリで並行して他のメンバーによって進められていた変更と意味的にもテキスト的にも重なることはほとんどないはずで、そうした場合には、後から完成したトピックを統合する前にリベースして最終的に記録される歴史を直線化することで、後から開発履歴を調べる際にスキップしないといけない不要なマージコミットを少なくすることができます。

プロジェクト全体の方針が新しい変更が必ず最新状態の上にリベースされていることを要求していなくても、トピックを新しく統合する前にリベースが容易に可能であればリベースするようにするのが、共同作業に参加するプロジェクトメンバーの良いしつけであると言えるでしょう。

入門 Git - Chapter 8. 分散環境とブランチの関連（p.118-120）

ちょっとまだ理解不足な部分も多いのですが、例えば、以下のような話でしょうか。

Non-FastForward によるマージを基本方針としている場合でも、容易に rebase 可能（≒コンフリクション無で rebase 可能？）な時は rebase してから merge すると、後から歴史を見た時や巻き戻す時に楽になると言う事が有り得るかもしれません。ただ、まだもやもやしてる部分もあるので、しばらくは「公開リポジトリにプッシュしたコミットをリベースしてはいけない」と言う指針のみ頭に入れて、試行錯誤して行こうかと思います。

Related Pages

• Git - Book
• 入門Git, 濱野 純
• こわくない Git
• rebaseはコミットグラフを綺麗にするためじゃなくてffマージをするためにあるのであった

前回、 git の運用指針 - Life like a clown と言う記事を書きましたが、git の事をよく理解しない状態のまま取り急ぎ作成したために、やはりいろいろとまずい所があったようです*1。指摘された点としては、「merge や rebase の理解がまずい」、「git-flow はしんどいから GitHub Flow の方が良い」辺りがありました。これらに関しては一つずつ調べながら、自分が理解した範囲で一度まとめてみようと思います。取りあえず、今回は git merge から。

尚、merge や rebase について調べていると こわくない Git と言う非常に分かりやすくて良い資料（スライド）が見つかりました。git 上で何らかのブランチ戦略を取って開発を行う場合、ひとまずこの資料に目を通す（通させる）と良いかもしれません。

git merge (Non Fast-Forward) 概要

git merege の概要に関しては Git - ブランチとマージの基本 に詳細な説明がありました。尚、git では下記の iss53 のような「何らかの機能追加や修正のために一時的に作成されたリポジトリ」をトピックブランチと呼ぶそうです。また、下記の図のように git では一連のコミットの履歴を有向グラフで表現する事が多く、これをコミットグラフ（入門 Git ではコミット家系図 (commit ancestry graph) と表記）などと呼んだりもするようです。

マージ先のコミットがマージ元のコミットの直系の先祖ではないため、Git 側でちょっとした処理が必要だったのです。ここでは、各ブランチが指すふたつのスナップショットとそれらの共通の先祖との間で三方向のマージを行いました。図 3-16 に、今回のマージで使用した三つのスナップショットを示します。

単にブランチのポインタを先に進めるのではなく、Git はこの三方向のマージ結果から新たなスナップショットを作成し、それを指す新しいコミットを自動作成します (図 3-17 を参照ください)。これはマージコミットと呼ばれ、複数の親を持つ特別なコミットとなります。

マージの基点として使用する共通の先祖を Git が自動的に判別するというのが特筆すべき点です。CVS や Subversion (バージョン 1.5 より前のもの) は、マージの基点となるポイントを自分で見つける必要があります。これにより、他のシステムに比べて Git のマージが非常に簡単なものとなっているのです。

これで、今までの作業がマージできました。

Git - ブランチとマージの基本

これらの記述を読んで、最初に思った事は「自分が思っているよりもはるかに賢いんだな」と言う事でした。前回の記事で「トピックブランチの修正中にメインブランチ (develop) に何らかの修正が加えられた場合、それを直ちにトピックブランチにも反映する」と言う指針を立てたのは、できるだけ早い段階で修正を反映しておかなければ（トピックブランチからメインブランチへの）マージ時に何か変な事*2になるのではないか、と言う不安からでした。「マージがなんとなく怖い」と言う こわくない Git で紹介されていた git 初心者の心理そのまま、と言う感じです（苦笑）。

しかし、上記の説明やその他の記事を読んでいるうちに、（同じファイルが修正された等の）コンフリクトが発生しそうな場合や修正箇所が該当のトピックブランチの挙動にも関わってくる（トピックブランチでの開発を進める上でメインブランチの修正が必要）場合を除けば、該当のトピックブランチで修正している間は、メインブランチの変更は無視しても構わないのだなと言う気になりました。

マージは常に Non Fast-Forward でと言う議論

git に関する資料を読んでいて、気になっていた事の一つに「マージは常に Non Fast-Forward で行う (git merge -no-ff <branch>)」と言う規則を設けている事が多い、と言うものがありました。

こわくない Git では、Fast-Forward によるマージの弊害として、以下の 2 点が挙げられていました*3。

1. 「ブランチをマージした」という事実が歴史（コミットグラフ）に残らない
2. 「ブランチのマージ」を取り消しづらい

その他、git log --first-parent と言うコマンドを用いて「修正履歴を見やすくする」と言う事を考えた場合にも Non Fast-Forward によるマージは必要と言う意見がありましたが、いずれに関しても、ある機能に関わる修正（コミット）がどこからどこまでなのかを分かりやすくする、と言う事が、実際の開発・運用に関しては重要になってくる場面も多いため、そう言った戦略が取られるようです。

これは個人的な話ですが、git に関する各種解説を読んでいるうちに「git においては、できるだけコミットグラフを一直線に保つことが良いとされているんだ。だから、可能であれば各種コマンド （Fast-Forward の merge や rebase）を用いて早い段階でコミットグラフを一直線にすべきだ」と言う気になっていました。

しかし、git （と言うか VCS）の目的はあくまで「多人数による開発のための管理や不意の事態（機能の逆戻り等）への対応」をしやすくする事にあるので、そう言った事を考慮せずに「コミットグラフに一直線に保つかどうか」に固執すると言うのは本質からずれる、と言う感じもします。なかなか難しい問題ですが、「実際の開発・運用においては何がベストか」をよく検討して指針を立てられるようにしていきたいと思います。

git merge に関する指針（未完成）

• トピックブランチで修正中は、基本的には、メインブランチへの修正は無視（保留）して良い。
• トピックブランチからメインブランチへのマージは、基本的には、Non Fast-Forward で行う（修正量的に軽度のバグフィックスを行う場合は、Fast-Forward でも良い？ような気もするが、要検討）。
• メインブランチの修正がトピックブランチでも必要になった場合は、どうやって取り込む？普通に git merge <main-branch> とか？

自分は今のところ、remoteにpushしてない手元だけのトピックブランチはrebaseを使ってmasterに追従しておいて、一度でもremoteにpush(pull req)したらそれ以降はmergeを使う、としてます。 URL

2013-04-15 10:45:48 via Hatena

Related Pages

• Git - Book
• こわくない Git
• 「こわくない Git」というスライドを発表しました - kotas.tech
• rebaseはコミットグラフを綺麗にするためじゃなくてffマージをするためにあるのであった

ソフトウェア開発に関しては、これまでほぼ一人で完結していた*1ので git の運用方法もかなり適当だったのですが（ただのコミットマシーン状態）、今回、同一プロジェクトに対して複数人でコミットしていく形になっているので、その状態だとやはりまずいなと言う気がしてきました。ググっていると「なるほど」と思う記事もたくさんあったので、それらの記事を元に自分のプロジェクトの「git の運用指針」を情報共有のために記載しておこうと思います。

前提

まず始めに、現在のプロジェクトの状況は下記のようになっています。

• 開発は 1 人のメインコミッタ（私）と数人のサポートコミッタ（アルバイト等）で行われる
• メインコミッタはフルタイム、サポートコミッタは週に数時間〜10時間程度の勤務形態
• サポートコミッタに対しては、基本的に 1 機能（1 チケット）を 1 人で完結するように作業を配分するが、時間的な兼ね合いもあり、作業途中でサポートコミッタからメインコミッタに作業を引き継ぐ場合もある

git-flow によるブランチ管理

git の運用についてググっていると、「git-flow」と言う単語をぽつぽつ目にしました。git-flow とは「ブランチモデル（ブランチの切り方）」を表しているそうです。これに関しては、Git flowの活用事例 によくまとまっている図が掲載されていました。

2 系統ブランチと命名規則

Git flow の活用事例（17/63）

上記を参考に、自分のプロジェクトでのブランチの運用指針を記載します。基本的な指針として、開発時はメインブランチを develop とします。何らかの機能を追加・修正する際には develop ブランチから派生ブランチを作成し、作成したブランチ上で作業を行います。develop ブランチ上では、決して作業を進めてはいけません。

1. サポートコミッタは、開発作業としてチケット*2を割り当てられたら、まず feature/<ticket> と言う形（<ticket> は修正する機能を表す適当な名前）で develop ブランチから派生ブランチを作成します。
   git checkout -b feature/<ticket> develop
   複数のチケットを 1 日で終了させるケースも考えられますが、1 日の作業は基本的には 1 つの派生ブランチで行う事とします（名前は適当に考える）。
2. サポートコミッタは、1 日の作業の終わりの際には、どんなに不完全であったとしても作業していた派生ブランチをリモートリポジトリへ push します。
   git push origin feature/<ticket>
   作業が完結しなかった場合は、未実装項目や問題点等を該当チケットのコメント欄、または口頭等で報告して作業を終了します。
3. メインコミッタは、リモートリポジトリに push された派生ブランチを取得し、レビュー・修正等を行った後、develop ブランチにマージします。作業が完了した場合は、該当ブランチは削除します。
   git checkout develop
   git merge feature/<ticket>
   git branch -d feature/<ticket>
   git push origin :feature/<ticket>
4. サポートコミッタは、次回の勤務時に前回 push したブランチがリモートリポジトリにまだ残っていた場合は、引き続きそのブランチで作業を行います。その際、作業の開始時に develop ブランチの内容を比較し、コミットが進んでいた場合は rebase してから作業を再開します。 rebase する、と言う部分は保留とします。
   git fetch
   git checkout develop
   git merge origin/develop
   git checkout feature/<ticket>
   git merge origin/feature/<ticket>
   git rebase develop
   リモートリポジトリから各ブランチの最新の内容を反映した後、develop ブランチを rebase できればいいです。git pull でも良いのですが、変なブランチにマージしてしまいそうなので上記としています（後述）。

その他

現時点で自分が気になっている点について記述していきます。精査している訳ではないので、内容は随時、加筆・修正されていきます。

git merege

git merge に関するメモ - Life like a clown を参照して下さい。

git rebase

git rebase に関するメモ - Life like a clown を参照して下さい。

git add

よくあるのが「git add . ってやったらサイズの大きなゴミファイルがリポジトリに紛れ込んでしまった」と言うものがあります。この運用方針を決めようと思ったのも、これに近い事例が原因でした。一応、.gitignore でいろいろフィルタリングしてるので多くの場合では適当に add しても大丈夫なのですが、漏れがあったりする事もあるので、add する際には必要なファイルのみを新たに追加 (git add) すると言う事を心掛けて下さい。

git pull

git pull の挙動がよく分かってなかったのですが、下記の記事を読んで何となく分かってきました。

• Git pullを使うべきでない３つの理由 - DQNEO起業日記
• git pullの詳細な挙動を追ってみる - hokaccha.hamalog v2

上記でも少し触れましたが、複数のブランチを用いて開発を進める場合、現在のローカルブランチの確認を怠ってうっかり「git pull origin feature/<ticket>」とかやったりすると、develop ブランチとかにマージしてしまったりして阿鼻叫喚になりそうな予感がしました。そう言えば、新しいリモートブランチを持ってくる際には、私もよく嵌っていました……

• hogeというリモートブランチをローカルのhogeブランチにもってきたい
• hogeをローカルのmasterにはマージしたくない
• pullでなんかこんな感じでいけそう？

$ git pull origin hoge:hoge

でもこれは間違えで、なぜか今いるブランチ（master）にhogeがmergeされるし、期待してる動作じゃない。正解はこう。

$ git branch hoge origin/hoge

もしくはチェックアウトも同時にするなら

$ git checkout -b hoge origin/hoge

こう。

git pullの詳細な挙動を追ってみる - hokaccha.hamalog v2

事故を防ぐ意味でも、いったん git fetch でダウンロードした後、git branch -av 等でブランチ状況を確認しながら、git checkout, git merge, git rebase 等のコマンドを利用して適切にマージ（または、rebase）して下さい。

参考 URL

基本的な内容として、ひとまず以下に目を通してみると良いかと思います。

• Git - Book
• こわくない Git
• Git初心者が絶対に覚えておくべきコマンド - idesaku blog
• ぼっちプログラマがチームに入る前に知っておきたい６つの git コマンド

その他（随時、更新予定）。

• Git ユーザマニュアル (バージョン 1.5.3 以降用)
• git-flow によるブランチの管理 - O’Reilly Japan Community Blog
• Git flowの活用事例
• GitHub Flow (Japanese translation)
• Git と GitHub を体験しながら身につける勉強会行ってきた - ぐるぐる?

書籍情報。

• 入門Git, 濱野 純
• 入門git, Travis Swicegood (著), でびあんぐる (翻訳)

アプリケーションを開発する際、最終的なアイコン等の UI 素材はデザイナの方に作ってもらうのですが、開発途中等で方向性が決まっていない段階では取りあえず適当なアイコンを適用して開発を進める事がしばしば存在します。この際に「取りあえずの適当なアイコン」を毎回 Web 上で探すのがめんどうになってきたので、何か良いものがないかなぁと思っていると、自分の需要に非常によくマッチした素晴らしいアイコン素材集がありました。

• Free Must Have Windows 7 Icons from VisualPharm

「開く」、「保存する」、「コピー」、「ペースト」等の Windows のソフトウェアでよくあるような UI に対して、「よく見る」ようなアイコンが一通り揃っています。微妙に足りない部分もあるにはあるのですが、開発版用としてはまずまず困らない位にまとまっています。

尚、そう言った類のアイコンの一部は Windows 各種 dll (shell32.dll, imageres.dll, ...) が標準で保持しているのですが、その一覧を掲載している記事もありました。上記と合わせて使用するとアイコンで悩まなくて済みそうです。

• Windows Icons: Reference list with details, locations & images

その他、上記で足りない場合は Icon Archive で探すと良い感じでしょうか。

アイコン一覧

以下は、Free Must Have Windows 7 Icons from VisualPharm でダウンロードできるアイコンの一覧です。

Related Pages

• Free Must Have Windows 7 Icons from VisualPharm
• Crystal Clear - Wikimedia Commons (from b:id:teramako)
• Windows Icons: Reference list with details, locations & images
• Icon Archive - Search 436,218 free icons, desktop icons, download icons, social icons, xp icons, vista icons

先日、Visual C# 2010 上で UserControl を継承したコンポーネントをデザイナ経由で貼り付けていたら、「ビルドは成功するんだけど、デザイナ上で表示しようとするとエラーになる」と言う状況に遭遇しました。適当にググっていたら「作成したコンポーネントにデフォルトコンストラクタが定義されていない場合にエラーになる」と言う情報が結構ヒットしたので確認してみたのですが、特に問題なし。

どうしたものかなと悩んでいたのですが、最終的には「x64 で開発していたから」と言うものでした。

デザイン時に、そのユーザーコントロールを含むアセンブリが Visual Studio によって読み込まれることでコントロールの配置、表示、シリアライズなどができるようになっています。しかし、Visual Studio はすでに指摘のあるとおり、x86 アプリケーションです。このため、x64 のアセンブリを読み込むことができず、エラーになっているのではないでしょうか。

x64プラットフォームで、ユーザーコントロールを使用したフォームのデザインが出来ない

自分の環境が 64bit 版 Windows である事と、リリースする際には一応 x86/x64 版を分けて出している事から、普段 Visual Studio で開発する際には x64 に設定している事が多いのですが、UserControl を使用するようなコーディングを行う時は x86 か Any CPU でやる方が無難のようです。

所用でさくら VPS に Redmine をインストールしていました。基本的には さくらのVPS を使いはじめる | アカベコマイリ で書かれている通りにやっていけば良いのですが、いくつか違うところもあったのでメモ。OS はデフォルト (CentOS 6.2 x86_64) のままです。

MySQL のインストールまで

特に問題となった箇所はなし。

• さくらのVPS を使いはじめる | アカベコマイリ
• さくらのVPS を使いはじめる 2 – sudo と SSH ポート変更 | アカベコマイリ
• さくらのVPS を使いはじめる 3 – iptables を設定する | アカベコマイリ
• さくらのVPS を使いはじめる 4 – Apache のインストールと初期設定 | アカベコマイリ
• さくらのVPS を使いはじめる 5 ? MySQL のインストールと初期設定 | アカベコマイリ

Ruby のインストール

• さくらのVPS を使いはじめる 6 – Ruby と Passenger | アカベコマイリ
• さくらのVPS を使いはじめる 7 – Ruby EE、Passenger、Redmine | アカベコマイリ

gem を叩くと libyaml をインストールしろと言う警告が出ました。ruby をインストールする前に、libyaml と libyaml-devel をインストールしておく必要があるようです。

# yum install libyaml
# yum install libyaml-devel

もう少し足りないモジュールがあったような気もしますが、まぁエラーメッセージ見て適当に yum 叩けば何とかなるレベルでした。後、この記事では Redmine のインストール中に何らかの問題に遭遇して Ruby を 1.8.7 に落としていますが、現在のバージョン (Redmine 1.4.0) だと Ruby 1.9.3 (1.9.3-p125) でも問題なくインストールできたので、特に落とす必要はないかと思います。

Redmine のインストール

Redmine のインストールは、公式ページのインストール手順を見て行いました。

• Redmineのインストール — Redmine Guide 日本語訳

まっさらな状態からやっていくと ImageMagick がインストールされておらず rmagick のインストールでコケたので、先に ImageMagick をインストールしておきます。

# yum install ImageMagick
# yum install ImageMagick-devel

次は、bundle でコケました。エラーは pg_config がないとの事。ググると PostgreSQL 周りのモジュールのようです。めんどくさいので、後述されている postgresql と sqlite 関連のものはインストールしない設定で。

# bundle install --without development test postgresql sqlite

最後は、MySQL のアダプタでコケました。インストール手順にもはっきりと「Ruby 1.9.x の場合は mysql2 を設定しろ」と書いてあるのに、なかなか気づけませんでした・・・人生そんなものです。

config/database.yml を以下のように修正します。

production:
adapter: mysql2
database: redmine
host: localhost
username: redmine
password: my_password

Related Pages

• Redmine.JP
• さくらのVPS を使いはじめる | アカベコマイリ
• さくらのVPS を使いはじめる 2 – sudo と SSH ポート変更 | アカベコマイリ
• さくらのVPS を使いはじめる 3 – iptables を設定する | アカベコマイリ
• さくらのVPS を使いはじめる 4 – Apache のインストールと初期設定 | アカベコマイリ
• さくらのVPS を使いはじめる 5 ? MySQL のインストールと初期設定 | アカベコマイリ
• さくらのVPS を使いはじめる 6 – Ruby と Passenger | アカベコマイリ
• さくらのVPS を使いはじめる 7 – Ruby EE、Passenger、Redmine | アカベコマイリ
• さくらのVPS を使いはじめる 8 – Redmine と Subversion | アカベコマイリ
• さくらのVPS を使いはじめる 9 – phpMyAdmin 導入と Redmine 更新 | アカベコマイリ
• さくらのVPS サーバ構築メモ - コムギドットネット
• U2Kの覚え書き　redmineでチケットとかにファイルを添付した時にエラーが出た時の対処法

最近，ちょっとしたアプリケーションのインストーラを書く機会が増えてきました．インストーラは Inno Setup で作成しているのですが，毎回，似たようなスクリプトファイルを記述するのは面倒になってきました（以前の Inno Setup 用 IDE であれば，IDE がテンプレートを自動生成してくれたのですが，これも微妙に修正する箇所があったりなかったり）．そんな訳で，ある程度，汎用的に使っていけるテンプレート（スケルトン）用のスクリプトファイルを作成してみました．

ダウンロード

https://github.com/clown/inno-templates から．使い方は，README を読むと大体分かるかと思います．README の内容をここにも記述しておきます．

ファイル構成

inno-templates では，以下のようなファイル構成を想定しています．

{#ROOT_PATH}
    + setup
        - setup.iss
        - process.iss
        - windows.iss
    + {#RESOURCE_DIR}
        + x86
            - {#APP_EXE_NAME}.exe
        + x64
            - {#APP_EXE_NAME}.exe
        - Readme.txt
        - License.txt
        - {#APP_EXE_NAME}.ico
        - ...

アプリケーション本体は，x86/x64 両方のバージョンが存在するケースを想定して書かれていますので，どちらか一方のエディションしか用意しない場合でも，x86/x64 のフォルダを作成した上で，そのフォルダにアプリケーション本体を設置して下さい．尚，各種テキストファイル（Readme.txt, License.txt），およびアイコン画像ファイルは省略する事も可能です．詳細は，「パラメータ設定」の項目で記述します．

パラメータ設定

inno-templates では，以下のパラメータが設定されています．これらは，setup.iss の上部で定義されており，これらを変更する事によってインストーラが作成されます．

X64_INSTALL_MODE

必須項目です．このパラメータを 0 にすると 32bit 用のインストーラが，1 以上に設定すると 64bit 用のインストーラが作成されます．尚，上記のファイル構成に関連した注意事項として，0 に設定すると x86 フォルダ以下のファイルを 1 以上に設定すると x64 フォルダ以下のファイルを参照するようになります．

GUID_VALUE

必須項目です．インストーラに固有の GUID を割り当てます．開発環境として InnoIDE を使用している場合，「Inno Scripts」→「Insert GUID」メニューを選択する事により新たな GUID を生成する事ができます．

ROOT_PATH

必須項目です．各種スクリプトファイルやインストールするリソース群が置かれているフォルダのルートとなるパスを選択します．

RESOURCE_DIR

必須項目です．アプリケーション本体や各種テキストファイル等のリソースが格納されているフォルダ名を指定します．初期値には "release" が指定されています．例えば，ROOT_PATH が "C:\myproject" であった場合，setup.iss は各種リソースファイル群が "C:\myproject\release\" 以下に存在すると想定します．

APP_NAME

必須項目です．インストーラを作成するアプリケーションの名前を設定します．

APP_EXE_NAME

必須項目です．メインとなるアプリケーションの exe 名を設定します．スクリプトファイル中では {#APP_EXE_NAME}.exe と記述しています．そのため，ここで設定するファイル名は ".exe" を除いた名前となります．

APP_VERSION

オプションです．アプリケーションのバージョンを設定します．省略する場合は，パラメータ自体は削除せずに "" を設定して下さい．

APP_RELEASE_YEAR

オプションです．アプリケーションのリリース年を設定します．スクリプトファイル内では現在のところ，コピーライト表記でのみ使用しています．
Copyright (c) {#APP_RELEASE_YEAR} {#APP_PUBLISHER}
省略する場合は，パラメータ自体は削除せずに "" を設定して下さい．

APP_PUBLISHER

必須項目です．アプリケーションの作成者の名前を設定します．

APP_URL

必須項目です．アプリケーションの配布，または説明をしている Web ページの URL を指定します．
※APP_URL を指定しない場合，[Icons] セクションの Filename: {#APP_URL} となっている行を削除した後，パラメータ自体は削除せずに "" を設定して下さい．

APP_LICENSE

オプションです．アプリケーションのライセンスが記述されているファイルのファイル名を設定します．スクリプトファイル内では，このファイルは {#ROOT_PATH}\{#RESOURCE_DIR} 下に存在している事を想定しています．このファイルに記述されている内容が，インストーラ実行時の「使用許諾契約書の同意」のダイアログで表示されます．ファイルが存在しない場合は，このパラメータを削除して下さい．

APP_README

オプションです．アプリケーションの説明が書かれているファイルのファイル名を設定します．スクリプトファイル内では，このファイルは {#ROOT_PATH}\{#RESOURCE_DIR} 下に存在している事を想定しています．ここで設定されたファイルが，インストーラの最後に「Readme.txt を表示する」と言った選択肢として表示されます．ファイルが存在しない場合は，このパラメータを削除して下さい．

APP_ICON

オプションです．アプリケーションのアイコンとして使用されている画像ファイルを設定します．ここで設定された画像がインストーラのアイコンとして使用されます．ファイルが存在しない場合は，このパラメータを削除して下さい．

setup.iss のデフォルトの挙動

ファイル関連

{#APP_EXE_NAME}.exe（アプリケーション本体），および {#APP_README}（説明用のテキストファイル）がインストールされます．APP_README パラメータを削除した場合は，アプリケーション本体のみがインストールされます．

レジストリ関連

HKEY_LOCAL_MACHINE\Software\{#APP_PUBLISHER}\{#APP_NAME} 下に以下の値が設定されます．

• InstallDirectory ..... ユーザが選択したインストールフォルダ
• Version ..... アプリケーションのバージョン（APP_VERSION で指定した値）

ショートカット関連

スタートメニュの「すべてのプログラム→{#APP_PUBLISHER}→{#APP_NAME}」下に以下のショートカットが設定されます．

• アプリケーション本体 ..... {#APP_EXE_NAME}.exe を実行するショートカット
• Web ページへのリンク ..... {#APP_URL} で指定した URL を規定のブラウザで開くショートカット
• アンインストール ..... アプリケーションをアンインストールするためのプログラムへのショートカット

また，これとは別にデスクトップにアプリケーション本体へのショートカットを作成するかどうかの

オプションをダイアログで表示するように設定されています．

その他

[Code] セクションにおいてもいくつかの機能をデフォルトで実装しています．

インストールするアプリケーションが実行されているかどうかのチェック

アプリケーションをアップデートする等の理由で，既にアプリケーションがインストールされているにも関わらず，再度インストーラを実行する場合があります．そういった場合に，インストーラ起動時にアプリケーション本体が実行されているとインストールに失敗します．また，アンインストール時に置いても同じような問題が発生します．そのため，インストーラ，およびアンインストーラの起動直後にアプリケーションが実行されているかどうかをチェックし，実行されている場合は強制終了する KillProc() 関数を実装しています．

尚，KillProc() 関数は，64bit 用であっても Inno Setup で生成されるインストーラプログラム自体は 32bit 版であるため 64bit 用の場合にはうまく機能しません（ 32bit プロセスは 64bit プロセスを見つけられない - Life like a clown 参照）．64bit 版でこの機能を実現する場合，プロセスを終了させるためだけの 64bit プログラムを作成し，そのプログラムをインストーラに含める等の回避策を取る必要があります．

Microsoft .NET Framework ランタイムがインストールされているかどうかのチェック

Microsoft .NET Framework を用いて開発されたアプリケーションは，インストールされる環境にランタイムがインストールされてある必要があります．そのため，インストーラの起動直後にMicrosoft .NET Framework ランタイムがインストールされてあるかどうかをチェックし，インストールされていない場合にはエラーメッセージを表示する機能を実装しています．

尚，この機能はデフォルトではコメントアウトされています．必要な場合は，InitializeSetup() 関数内の該当箇所のコメントアウトを解除します．

Related Pages

• clown/inno-templates ? GitHub
• Inno Setup
• Inno Setup Help
• 32bit プロセスは 64bit プロセスを見つけられない - Life like a clown

Ghostscript のオプションのうちで分かりにくいものに -d オプションと -s オプションがあります．特に -dKey=Value の形になっているオプションに関しては，どちらを使って良いか分からない場合も多いです．

-s オプションの Value はどうも「名前」を表しているようです．PostScript や PDF の名前には先頭に "/" (スラッシュ)が付くのですが，-sKey=Value の形でオプションを指定すると Value を「名前」と判断して Value の先頭に自動的に "/" を付加するようです．

例えば，以下の 2つのオプションはどちらを指定してもまったく同じ意味になります．

-dProcessColorModel=/DeviceCMYK
-sProcessColorModel=DeviceCMYK

以上から，Ghostscript の -s と -d オプションの使い分けは以下のようになります．

• -sDEVICE，-sOutputFile などは -s オプションとしてしか指定できない．
• -dKey の形になっているオプションは -s オプションでは代替不可能．
• -dKey=Value の形になっているオプションは，Value の先頭に "/" (スラッシュ) が付いている場合はそのスラッシュを除いた上で -s オプションで代替可能．

Ghostscript はオプション指定の仕方で結構いろいろな事ができるようなのですが，まだまだ把握しきれていない部分が多いです．

Ghostscript でフォント埋め込み指定した場合 (-dEmbedAllFonts=true)，Base 14 Fonts と呼ばれる基本フォント (Courier, Courier-Bold, Courier-Oblique, Courier-BoldOblique, Helvetica, Helvetica-Bold, Helvetica-Oblique, Helvetica-BoldOblique, Times-Roman, Times-Bold, Times-Italic, Times-BoldItalic, Symbol, ZapfDingbats の 14個) については埋め込まないようになっているようです．

ただし，PDF/X や PDF/A と呼ばれるフォーマットの場合，これらのフォーマットの要求事項に「全てのフォントを埋め込む事」と言う指定があるため，Base 14 Fonts も埋め込まれるようです．実際， Ghostscript で PDF/X ファイルを作成する - Life like a clown でテストした際にも，PDF/X の場合は Times-Roman フォントが埋め込まれていました．

PDF/A や PDF/X 以外の普通の PDF 形式でも全てのフォーマットを埋め込みたい場合には，以下のコードを修正する事で可能になるようです．

欧文基本14書体を PDF に埋め込むには

Ghostscript は、標準では PostScript Level 1 欧文基本14書体を PDF に埋め込まない。これが好ましくない場合には以下のようにする。

[/opt/local/share/ghostscript/9.02/Resource/Init/gs_pdfwr.ps]
...
/.standardfonts [
%  /Courier /Courier-Bold /Courier-Oblique /Courier-BoldOblique
%  /Helvetica /Helvetica-Bold /Helvetica-Oblique /Helvetica-BoldOblique
%  /Times-Roman /Times-Bold /Times-Italic /Times-BoldItalic
%  /Symbol /ZapfDingbats
] readonly def
...

Beginning OS X Lion/運用編 - Beginning OS X

ただし，Resource/Init/* にあたるファイル群は，Windows 版のオリジナル Ghostscript だとバイナリとして埋め込まれてる？ようなので，Windows 版でこの修正を行う場合には，恐らく，Ghostscript 自体を再ビルドする必要があります．尚，日本語版 Ghostscript と呼ばれている修正バージョンでは，Resource/Init/* のファイルを分離して再ビルドしているようなので，こちらを使用する場合には該当する PostScript ファイルを修正するだけで変更できるようです．

Related Pages

• PDF/A - Wikipadia
• PDF/X - Wikipedia

Ghostscript で PDF/X ファイルを作成するには，-dPDFX オプションを付ければ良いようです．ただし，PDF/X には CMYK じゃないとダメ等の制限があるので，実際には以下のような設定が必要になります．

• -sDEVICE=pdfwrite を指定する．あるいは，ps2pdf スクリプトを使用しても良い．
• -dPDFX オプションを付ける．このオプションを付けると PDF バージョンは強制的に 1.3 になる模様．
• -sProcessColorModel=DeviceGray か -sProcessColorModel=DeviceCMYK を設定する．RGB は不可．
• デバイスに依存しない PDF ファイル？を作成する場合は，-dUseCIEColor オプションを付ける．
• PDF/X に変換するための定義ファイルを指定する．省略すると gs/lib/PDFX_def.ps が使用される模様．

尚，PDF/A ファイルに関してもほとんど同様の方法（-dPDFX を -dPDFA に変える）で生成する事ができます．

テスト

取りあえず，Ghostscript をインストールすると付いてくるサンプルファイルのうち，colorcir.ps でテストしてみました．

普通の PDF

$ gswin32c.exe -dBATCH -dNOPAUSE -dNOOUTERSAVE -sDEVICE=pdfwrite
-sOutputFile=colorcir.pdf colorcir.ps

生成結果 (PDF)

PDF/X

$ gswin32c.exe -dPDFX -dBATCH -dNOPAUSE -dNOOUTERSAVE -sDEVICE=pdfwrite
-sProcessColorModel=DeviceCMYK -sColorConversionStrategy=CMYK
-sOutputFile=colorcir.pdf colorcir.ps

生成結果 (PDF/X, -sColorConversionStrategy=CMYK オプション付き)

追記 どうやら RGB のファイルを CMYK に変換する場合，-sProcessColorModel=DeviceCMYK オプションだけでは不十分で，-sColorConversionStrategy=CMYK オプションも付ける必要があるようです(参考: linux - Converting PDF to CMYK (with identify recognizing CMYK) - Stack Overflow)．

PDF/X (UseCIEColor オプション付)

$ gswin32c.exe -dPDFX -dBATCH -dNOPAUSE -dNOOUTERSAVE -sDEVICE=pdfwrite
-sProcessColorModel=DeviceCMYK -sColorConversionStrategy=CMYK -dUseCIEColor
-sOutputFile=colorcir.pdf colorcir.ps

生成結果 (PDF/X, UseCIEColor オプション付)

カスタマイズ

カスタマイズは，PDFX_def.ps 辺りをベースにこれを修正する事でできるようです（カスタマイズしたら，入力ファイルの直前にそのファイル名を指定する）．カスタマイズ項目は，以下のように記述されていました．

As mentioned above, the PDF/X definition file provides special information, which the PDF/X-3 standard requires. You can find a sample file in gs/lib/PDFX_def.ps, and edit it according to your needs. The file follows Postscript syntax and uses the operator pdfmark to pass the special information. For your comfort we marked the lines likely to need editing in the sample file with the comment % Customize. They are explained below.

OutputCondition string

Defines an OutputCondition value for the output intent dictionary. OutputConditionIdentifier string Defines an OutputConditionIdentifier value for the output intent dictionary.

ICCProfile string

May be omited if OutputConditionIdentifier specifies a registed identifier of characterized printing condition see http://www.color.org/IPA_2003-11_PDFX.pdf). Defines a file name of an ICC profile file to be included into the output document. You may specify either an absolute file name, or a relative path from the working directory.

Title string

Defines the document title. Only useful if the source Postscript file doesnt define a title with DSC comments. therwise remove entire line from definition file.

Info string

Defines an Info value for the output intent dictionary.

ps2pdf: PostScript-to-PDF converter

ICC プロファイル辺りは使うかもしれません．