makefile-generator

Makefile ジェネレーター

概要

C/C++、Python、Go、Java、および汎用プロジェクト向けに、ベストプラクティスに沿った本番環境対応の Makefile を生成します。GNU Coding Standards への準拠、標準ターゲット、セキュリティ強化に加え、devops-skills:makefile-validator スキルによる自動検証に対応しています。

使用する場面

• 新しい Makefile を一から作成するとき
• プロジェクト（C/C++、Python、Go、Java）のビルドシステムをセットアップするとき
• ビルドの自動化と CI/CD の統合を実装するとき
• 手動のビルドプロセスを Makefile に移行するとき
• ユーザーが Makefile の「作成」「生成」「記述」を求めたとき

次の用途には使用しないでください： 既存の Makefile の検証（devops-skills:makefile-validator を使用）、デバッグ（make -d を使用）、またはビルドの実行。

トリガーフレーズ

次のようなプロンプトでは、このスキルを使用してください：

• 「Go サービス用の Makefile を生成して」
• 「install/test/help ターゲットを備えた本番用 Makefile を作成して」
• 「依存関係の追跡機能を備えた C プロジェクト用の Makefile を書いて」
• 「この既存の Makefile に標準的な GNU ターゲットを追加して」

生成ワークフロー

ステージ 1：要件の収集

次のカテゴリの情報を収集します。情報が不足している、または曖昧な場合は、AskUserQuestion を使用してください：

カテゴリ	必要な情報
プロジェクト	言語（C/C++/Python/Go/Java）、構成（単一ディレクトリ／複数ディレクトリ）
ビルド	ソースファイル、出力成果物、依存関係、ビルド順序
インストール	PREFIX の場所、ディレクトリ（bin/lib/share）、インストールするファイル
ターゲット	all、install、clean、test、dist、help（どれが必要か）
設定	コンパイラー、フラグ、pkg-config の依存関係、クロスコンパイル

AskUserQuestion を使用する場合（次のいずれかに該当する場合は必ず質問してください）：

条件	質問の例
言語が指定されていない	「このプロジェクトのプログラミング言語は何ですか？（C/C++/Go/Python/Java）」
プロジェクトの構成が不明確	「単一ディレクトリのプロジェクトですか、それとも複数ディレクトリのプロジェクトですか？」
Docker が求められているが、レジストリが不明	「どのコンテナレジストリを使用しますか？（docker.io/ghcr.io/custom）」
複数のバイナリを作成できる可能性がある	「単一のバイナリをビルドしますか、それとも複数の実行ファイルをビルドしますか？」
インストールターゲットが必要だが、パスが不明	「バイナリのインストール先はどこですか？（デフォルト：/usr/local/bin）」
クロスコンパイルへの言及がある	「ターゲットのプラットフォーム／アーキテクチャは何ですか？」

AskUserQuestion を省略する場合（デフォルトで進める）：

• ユーザーが必要な情報をすべて明示している
• 標準的なプロジェクト種別で、明らかなデフォルトがある（例：「Docker を使う Go プロジェクト」→標準的な Go と Docker のパターンを使用）
• ユーザーが「デフォルトを使用」または「標準設定」と指定している

デフォルトの前提（質問しない場合）：

• 単一ディレクトリのプロジェクト構成
• PREFIX=/usr/local
• 標準ターゲット：all、build、test、clean、install、help
• クロスコンパイルなし

ステージ 2：ドキュメントの参照

必須の場合（必ず参照してください）：

• なじみのないツール、フレームワーク、ビルドシステムとの統合をユーザーが求めている
• ステージ 3 の例で扱われていない複雑なビルドパターン（例：Bazel、Meson、カスタムツールチェーン）
• Docker／コンテナーとの統合（Dockerfile のビルド、マルチステージ、レジストリへのプッシュ）
• CI/CD プラットフォーム固有の統合（GitHub Actions、GitLab CI、Jenkins）
• 特殊なターゲットや組み込みシステム向けのクロスコンパイル
• パッケージマネージャーとの統合（Conan、vcpkg、Homebrew の formula）
• 複数のバイナリまたはライブラリを含むプロジェクト
• ldflags またはビルド時変数を使用したバージョンの埋め込み

任意の場合（外部参照を省略できます）：

• ステージ 3 ですでに扱われている標準的な言語パターン（C/C++、Go、Python、Java）
• 外部依存関係のない、単純な単一バイナリのプロジェクト
• ユーザーが曖昧さのない完全な要件を提示している
• 内部ドキュメントで必要なパターンがすでに十分に説明されている

参照手順（順番に実施してください）：

1. 必ず、明示的なファイルを開くコマンドを使って、まず内部ドキュメントを確認してください（最も信頼できる情報源）：

   ドキュメントのフルパスマップ（確実にアクセスできるよう、フルパスを推奨）：

   ドキュメント	フルパス
   構成ガイド	devops-skills-plugin/skills/makefile-generator/docs/makefile-structure.md
   変数ガイド	devops-skills-plugin/skills/makefile-generator/docs/variables-guide.md
   ターゲットガイド	devops-skills-plugin/skills/makefile-generator/docs/targets-guide.md
   パターンガイド	devops-skills-plugin/skills/makefile-generator/docs/patterns-guide.md
   最適化ガイド	devops-skills-plugin/skills/makefile-generator/docs/optimization-guide.md
   セキュリティガイド	devops-skills-plugin/skills/makefile-generator/docs/security-guide.md

   要件	参照するドキュメント
   Docker／コンテナーのターゲット	.../docs/patterns-guide.md（パターン 8：Docker 統合）
   複数バイナリを含むプロジェクト	.../docs/patterns-guide.md（パターン 7：複数バイナリのプロジェクト）
   バージョンを埋め込む Go プロジェクト	.../docs/patterns-guide.md（パターン 5：Go プロジェクト）
   並列ビルド、キャッシュ、ccache	.../docs/optimization-guide.md
   認証情報、シークレット、API キー	.../docs/security-guide.md
   複雑な依存関係、パターンルール	.../docs/patterns-guide.md
   順序のみの前提条件	.../docs/optimization-guide.md または .../docs/targets-guide.md
   変数、代入演算子	.../docs/variables-guide.md

   確実に開いて読み込むためのコマンド：

   # From repository root:
   sed -n '1,220p' devops-skills-plugin/skills/makefile-generator/docs/patterns-guide.md
   rg -n "Pattern 5|Pattern 8" devops-skills-plugin/skills/makefile-generator/docs/patterns-guide.md
   
   # From skill directory:
   sed -n '1,220p' docs/security-guide.md
   

   シェルコマンドを利用できない場合は、同じパスに対して環境のファイルを開く／読み込む機能を使用してください。

   必須ワークフローの例（Docker ＋ バージョン埋め込みを使う Go）：

   # Step 1: Read Go pattern
   rg -n "Pattern 5" devops-skills-plugin/skills/makefile-generator/docs/patterns-guide.md
   
   # Step 2: Read Docker pattern
   rg -n "Pattern 8" devops-skills-plugin/skills/makefile-generator/docs/patterns-guide.md
   
   # Step 3: Read security guidance
   sed -n '1,220p' devops-skills-plugin/skills/makefile-generator/docs/security-guide.md
   

   その後、Makefile を生成し、参照したドキュメントをヘッダーコメントに記載してください。

2. 外部ツールドキュメントの参照には、まず context7 を試してください（内部ドキュメントで特定のツールが扱われていない場合）：

   # Only needed for tools/frameworks NOT covered in internal docs
   mcp__context7__resolve-library-id: "<tool-name>"
   mcp__context7__query-docs: query="<integration-topic>"
   
   # Example queries:
   # - For Docker: query="dockerfile best practices"
   # - For Go: query="go build ldflags"
   # - For specific tools: query="<tool> makefile integration"
   

   フォールバック： context7 を利用できない場合、または有用な結果が返らない場合は、その旨を記録してステップ 3 に進んでください。

3. WebSearch にフォールバックしてください（内部ドキュメントにも context7 にも該当するパターンがない場合のみ）：

   "<specific-feature>" makefile best practices 2025
   Example: "docker makefile best practices 2025"
   Example: "go ldflags version makefile 2025"
   

   WebSearch を実行する条件： 内部ドキュメントで特定の統合方法が扱われておらず、context7 でも関連する結果が返らない場合。

注： 参照した内部ドキュメントを回答に記載してください（生成する Makefile のヘッダーにコメントを追加します）。

ステージ 3：Makefile の生成

ヘルパースクリプトを使った任意の高速パス（標準的な構成向け）：

# Generate template: TYPE NAME OUTPUT
bash scripts/generate_makefile_template.sh go myservice Makefile

# Add only selected standard targets
bash scripts/add_standard_targets.sh Makefile install clean help

要件が複雑な場合（Docker のリリースフロー、複数バイナリのマトリックス、カスタムツールチェーン）は、手動で作成してください。

ヘッダー（スタイルを 1 つ選択）

従来型（POSIX 互換）：

.DELETE_ON_ERROR:
.SUFFIXES:

モダン（GNU Make 4.0 以降、推奨）：

SHELL := bash
.ONESHELL:
.SHELLFLAGS := -eu -o pipefail -c
.DELETE_ON_ERROR:
.SUFFIXES:
MAKEFLAGS += --warn-undefined-variables
MAKEFLAGS += --no-builtin-rules

標準変数

# User-overridable (use ?=)
CC ?= gcc
CFLAGS ?= -Wall -Wextra -O2
PREFIX ?= /usr/local
DESTDIR ?=

# GNU installation directories
BINDIR ?= $(PREFIX)/bin
LIBDIR ?= $(PREFIX)/lib
INCLUDEDIR ?= $(PREFIX)/include

# Project-specific (use :=)
PROJECT := myproject
VERSION := 1.0.0
SRCDIR := src
BUILDDIR := build
SOURCES := $(wildcard $(SRCDIR)/*.c)
OBJECTS := $(SOURCES:$(SRCDIR)/%.c=$(BUILDDIR)/%.o)

言語固有のビルドルール

C/C++：

$(TARGET): $(OBJECTS)
	$(CC) $(LDFLAGS) $^ $(LDLIBS) -o $@

$(BUILDDIR)/%.o: $(SRCDIR)/%.c
	@mkdir -p $(@D)
	$(CC) $(CPPFLAGS) $(CFLAGS) -MMD -MP -c $< -o $@

-include $(OBJECTS:.o=.d)

Go：

$(TARGET): $(shell find . -name '*.go') go.mod
	go build -o $@ ./cmd/$(PROJECT)

Python：

.PHONY: build
build:
	python -m build

.PHONY: develop
develop:
	pip install -e .[dev]

Java：

$(BUILDDIR)/%.class: $(SRCDIR)/%.java
	@mkdir -p $(@D)
	javac -d $(BUILDDIR) -sourcepath $(SRCDIR) $<

標準ターゲット

.PHONY: all clean install uninstall test help

## Build all targets
all: $(TARGET)

## Install to PREFIX
install: all
	install -d $(DESTDIR)$(BINDIR)
	install -m 755 $(TARGET) $(DESTDIR)$(BINDIR)/

## Remove built files
clean:
	$(RM) -r $(BUILDDIR) $(TARGET)

## Run tests
test:
	# Add test commands

## Show help
help:
	@echo "$(PROJECT) v$(VERSION)"
	@echo "Targets: all, install, clean, test, help"
	@echo "Override: make CC=clang PREFIX=/opt"

ステージ 4：検証とフォーマット

生成されたすべての Makefile に対して検証が必要です。

検証ツールの事前確認（デフォルト＋フォールバック）

1. 優先する方法： devops-skills:makefile-validator を実行します。
2. バリデータスキルを利用できない場合： ローカルのフォールバックチェックを実行します。

   # Required fallback check (if make exists)
   make -f <Makefile> -n --dry-run
   
   # Structural fallback checks
   rg -n '^ {1,}\S' <Makefile>         # suspicious space-indented recipe lines
   rg -n '^\.PHONY:' <Makefile>
   

3. make を利用できない場合： 構造チェックのみを実行し、「make バイナリがないため検証は部分的です」と報告します。また、本番環境で使用可能であると判断する前に、ユーザーに確認を求めます。

必須の検証ループ

1. Generate Makefile following stages above
2. Run validator skill (or fallback checks if unavailable)
3. Fix all errors (MUST have 0 errors before completion)
4. Apply formatting fixes (see "Formatting Step" below)
5. Fix warnings when feasible (SHOULD fix; explain if skipped)
6. Address info items for large/production projects
7. Re-run validation until checks pass
8. Output structured validation report (REQUIRED - see format below)

フォーマット手順（必須）

mbake がフォーマットに関する問題を報告した場合、必ず次のいずれかを行います。

1. フォーマットを自動適用する（軽微な問題の場合はこちらを優先します）。

   mbake format <Makefile>
   

2. 適用しない理由を説明する（フォーマットによって機能が損なわれる場合）。

   Formatting not applied because:
   - [specific reason, e.g., "heredoc syntax would be corrupted"]
   - Manual review recommended for: [specific lines]
   

mbake がインストールされていない、または実行できない場合は、フォーマッターの実行をスキップし、次のように記録します。 Formatting skipped: mbake unavailable in current environment.

フォーマットの判断ガイド：

mbake の報告	対応
具体的な問題を伴わない "Would reformat"	mbake format で自動適用
空白やインデントに関する具体的な問題	mbake format で自動適用
複雑な heredoc や複数行文字列に関する問題	フォーマットをスキップし、出力で説明
# bake-format off セクション内の問題	スキップ（意図的に無効化されています）
mbake コマンドを利用できない	フォーマットをスキップし、ツールを利用できない理由を記録

検証の合格基準：

レベル	要件	対応
エラー（0 件必須）	構文エラー、タブの欠落、無効なターゲット	完了前に必ず修正します
警告（可能であれば修正）	フォーマットの問題、最適化の不足	修正することが望ましいです。スキップした場合は説明します
情報（本番環境向けに対応）	改善の提案、スタイルに関する推奨	本番環境向けの Makefile では対応することが望ましいです

既知の mbake の誤検知（安全に無視できます）：

mbake バリデーターは、有効な GNU Make の特殊ターゲットに対して警告を報告する場合があります。これらは誤検知のため、無視できます。

mbake の警告	実際の状態	説明
"Unknown special target '.DELETE_ON_ERROR'"	✅ 有効	失敗したビルド成果物を削除する、GNU Make の重要なターゲットです
"Unknown special target '.SUFFIXES'"	✅ 有効	サフィックスルールを無効化または設定する、GNU Make の標準ターゲットです
"Unknown special target '.ONESHELL'"	✅ 有効	1 つのシェルでレシピを実行する、GNU Make 3.82 以降の機能です
"Unknown special target '.POSIX'"	✅ 有効	POSIX 準拠を宣言します

検証レポートの出力（必須）

検証の完了後、以下の形式で構造化レポートを必ず出力してください。これは任意ではありません。

必須のレポート形式：

## Validation Report

**Result:** [PASSED / PASSED with warnings / FAILED]
**Errors:** [count]
**Warnings:** [count]
**Info:** [count]

### Errors Fixed
- [List each error and how it was fixed, or "None" if 0 errors]

### Warnings Addressed
- [List each warning that was fixed]

### Warnings Skipped (with reasons)
- [List each warning that was NOT fixed and explain why]
- Example: "mbake reports '.DELETE_ON_ERROR' as unknown - this is a valid GNU Make
  special target (false positive)"

### Formatting Applied
- [Yes/No] - [If No, explain why formatting was skipped]

### Info Items Addressed
- [List info items that were addressed for production Makefiles]
- [Or "N/A - simple project" if not applicable]

### Remaining Issues (if any)
- [List any issues requiring user attention]
- [Or "None - Makefile is production-ready"]

レポートの完全な出力例：

## Validation Report

**Result:** PASSED with warnings
**Errors:** 0
**Warnings:** 2
**Info:** 1

### Errors Fixed
- None

### Warnings Addressed
- Fixed: Added error handling to install target (|| exit 1)

### Warnings Skipped (with reasons)
- mbake reports ".DELETE_ON_ERROR" as unknown - this is a valid and critical
  GNU Make special target that ensures failed builds don't leave corrupt files.
  See: https://www.gnu.org/software/make/manual/html_node/Special-Targets.html

### Formatting Applied
- Yes - Applied `mbake format` to fix whitespace issues

### Info Items Addressed
- Added .NOTPARALLEL for Docker targets (parallel safety)
- Added error handling for docker-push target

### Remaining Issues
- None - Makefile is production-ready

対応が必要な一般的な情報項目：

情報項目	修正が必要な場合	修正方法
「順序のみの前提条件を持たない mkdir」	大規模プロジェクト（ターゲットが 10 個超）の場合	target: prereqs | $(BUILDDIR) のパターンを使用します
「レシピのコマンドにエラー処理がない」	重要な操作（インストール、デプロイ）の場合	.SHELLFLAGS に set -e を追加するか、&& でコマンドを連結します
「ccache の使用を検討」	コンパイルに時間がかかる場合	CC := ccache $(CC) のパターンを追加します
「並列実行の影響を受けるコマンドを検出」	Docker/npm/pip のターゲットの場合	対象のターゲットに .NOTPARALLEL: を追加するか、適切な依存関係を設定します

本番品質の要件（Docker／デプロイのターゲットでは必ず対応）：

Docker またはデプロイのターゲットを含む Makefile を生成する場合、以下の本番向けパターンを必ず適用してください。

1. docker-push のエラー処理：

   ## Push Docker image to registry (with error handling)
   docker-push: docker-build
   	@echo "Pushing $(IMAGE)..."
   	docker push $(IMAGE) || { echo "Failed to push $(IMAGE)"; exit 1; }
   	docker push $(IMAGE_LATEST) || { echo "Failed to push $(IMAGE_LATEST)"; exit 1; }
   

2. Docker ターゲットの並列実行の安全性：

   # Prevent parallel execution of Docker targets (race conditions)
   .NOTPARALLEL: docker-build docker-push docker-run
   

   または、適切な依存関係を設定して順次実行します：

   docker-push: docker-build  # Ensures build completes before push
   docker-run: docker-build   # Ensures build completes before run
   

3. install ターゲットのエラー処理：

   install: $(TARGET)
   	install -d $(DESTDIR)$(PREFIX)/bin || exit 1
   	install -m 755 $(TARGET) $(DESTDIR)$(PREFIX)/bin/ || exit 1
   

注： 検証でエラー処理や並列実行の安全性に関する情報項目が示された場合、Docker、デプロイ、または install のターゲットを含むすべての Makefile で必ず対応してください。適用したパターンを回答内で説明してください。

検証チェックリスト：

• 構文が正しい（make -n が成功する）
• ファイル以外のすべてのターゲットに .PHONY が指定されている
• タブでインデントされている（スペースではない）
• ハードコードされた認証情報がない
• ユーザーが上書き可能な変数には ?= を使用している
• .DELETE_ON_ERROR がある
• MAKEFLAGS の最適化が含まれている（Modern ヘッダー）
• ビルドディレクトリに順序のみの前提条件を設定している（大規模プロジェクトの場合）
• 重要なレシピ（install、deploy、docker-push）にエラー処理がある

ベストプラクティス

変数

• ユーザーが上書き可能な変数（CC、CFLAGS、PREFIX）には ?= を使用します
• プロジェクト固有の変数（SOURCES、OBJECTS）には := を使用します
• pkg-config を使用します：CFLAGS += $(shell pkg-config --cflags lib)

ターゲット

• ファイル以外のターゲットには必ず .PHONY を宣言します
• デフォルトのターゲットは all にします
• 安全のため .DELETE_ON_ERROR を使用します
• ヘルプターゲットには ## コメントで説明を記述します

ディレクトリの作成

ビルドディレクトリを作成する方法は 2 つあります。

シンプル（mkdir をインラインで実行）：

$(BUILDDIR)/%.o: $(SRCDIR)/%.c
	@mkdir -p $(@D)
	$(CC) $(CFLAGS) -c $< -o $@

最適化（順序のみの前提条件）： ディレクトリのタイムスタンプが変わったときに不要な再ビルドが発生するのを防ぎます。

$(BUILDDIR):
	@mkdir -p $@

$(BUILDDIR)/%.o: $(SRCDIR)/%.c | $(BUILDDIR)
	$(CC) $(CFLAGS) -c $< -o $@

多数のターゲットがある大規模プロジェクトでは、順序のみの前提条件（|）を使用します。

レシピ

• スペースではなく、タブを使用します
• シェル内では変数を引用符で囲みます：$(RM) "$(TARGET)"
• コマンドを表示しない場合は @ 接頭辞を使用します
• まず make -n でテストします

ヘルパースクリプト（任意）

これらのスクリプトは、テンプレートをすばやく生成するための任意の便利ツールです。

スクリプトと手動生成の使い分け

シナリオ	推奨
シンプルで標準的なプロジェクト（単一バイナリ、特別な機能なし）	✅ 速度を優先して generate_makefile_template.sh を使用します
複雑なプロジェクト（Docker、複数バイナリ、独自のパターン）	❌ 細かく制御できる手動生成を使用します
既存の Makefile にターゲットを追加する場合	✅ add_standard_targets.sh を使用します
ユーザーに特定の書式やスタイルの要件がある場合	❌ 手動生成を使用します
迅速なプロトタイピング／概念実証	✅ スクリプトを使用し、後でカスタマイズします
本番環境に対応した Makefile	⚠️ スクリプトから始めて、後で手動でカスタマイズします

generate_makefile_template.sh

特定のプロジェクトタイプ向けに、完全な Makefile テンプレートを生成します。 スクリプトのパス：scripts/generate_makefile_template.sh

bash scripts/generate_makefile_template.sh [TYPE] [NAME] [OUTPUT_FILE]

Types: c, c-lib, cpp, go, python, java, generic

例：

bash scripts/generate_makefile_template.sh go myservice
# Creates Makefile with Go patterns, version embedding, standard targets

bash scripts/generate_makefile_template.sh go myservice build/Makefile
# Writes template to build/Makefile (TYPE NAME OUTPUT)

add_standard_targets.sh

既存の Makefile に不足している標準的な GNU ターゲットを追加します。 スクリプトのパス：scripts/add_standard_targets.sh

bash scripts/add_standard_targets.sh [MAKEFILE] [TARGETS...]
bash scripts/add_standard_targets.sh [TARGETS...]  # uses ./Makefile

Targets: all, install, uninstall, clean, distclean, test, check, help, dist

例：

bash scripts/add_standard_targets.sh Makefile install uninstall help
# Adds install, uninstall, help targets if they don't exist

bash scripts/add_standard_targets.sh clean test
# Explicit-target mode: modifies ./Makefile

bash scripts/add_standard_targets.sh -n Makefile dist
# Dry-run mode: shows planned changes without editing files

注： ステージ 3 のパターンに従って手動で生成した場合も同等の結果になりますが、より柔軟にカスタマイズできます。

ヘルパースクリプトの回帰スモークテスト

ヘルパースクリプトまたはテンプレートを変更した後に実行します：

bash test/test_helper_scripts.sh

完了条件

以下のすべてのチェックを満たした場合にのみ、タスクを完了とします：

• トリガーが一致し、不足している要件が確認された（または文書化されたデフォルトが適用された）。
• 生成前に、明示的なファイルパスを使って関連する内部ドキュメントを開いた。
• 生成された Makefile で、ファイルを生成しないターゲットに .PHONY が漏れなく指定されている。
• Go テンプレートに、go.sum の任意対応と、設定可能な GO_MAIN エントリーポイントが含まれている。
• makefile-validator を使って検証した（推奨）。または、フォールバックチェックを文書化した。
• mbake でフォーマットを適用した。または、ツールを利用できない理由／互換性の問題を明示してスキップした。
• 最終回答に、指定された構造化検証レポートが含まれている。

ドキュメント

詳細なガイドは docs/ にあります：

• makefile-structure.md - 構成、レイアウト、インクルード
• variables-guide.md - 代入演算子、自動変数
• targets-guide.md - 標準ターゲット、.PHONY、前提条件
• patterns-guide.md - パターンルール、依存関係
• optimization-guide.md - 並列ビルド、キャッシュ
• security-guide.md - 安全な展開、認証情報の取り扱い

リソース

• GNU Make マニュアル
• GNU コーディング規約
• Makefile 規約