Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ビルドプロセスをデバッグしよう!
Search
Yuta Tomiyama
November 01, 2025
Programming
440
2
Share
ビルドプロセスをデバッグしよう!
2025/11/1 Kotlin Fest 2025 にて発表
Yuta Tomiyama
November 01, 2025
More Decks by Yuta Tomiyama
See All by Yuta Tomiyama
モバイルアプリ開発を始めよう!
yt8492
0
110
Git勉強会
yt8492
0
200
なんでもやってみる勇気
yt8492
0
130
Android Autoが思ったよりしんどい話
yt8492
0
240
apollo-kotlinにcontributeした話
yt8492
0
180
DMM TVのSDカードダウンロード機能を実装した話
yt8492
1
970
今だからこそ知りたいKotlin Multiplatform
yt8492
0
330
State management and API calls in Jetpack Compose: Learning Apollo + Jetpack Compose through React Hooks
yt8492
0
1.3k
サーバーフレームワークの仕組みが気になったので車輪の再発明をしてみた
yt8492
0
240
Other Decks in Programming
See All in Programming
決定論 vs 確率論:Gemini 3 FlashとTF-IDFを組み合わせた「法規判定エンジン」の構築
shukob
0
150
Claude Code × Gemini × Ebitengine ゲーム制作素人WebエンジニアがGoでゲームを作った話
webzawa
0
210
ソフトウェア設計の結合バランス #phperkaigi
kajitack
0
480
WebAssembly を読み込むベストプラクティス 2026年春版 / Best Practices for Loading WebAssembly (Spring 2026)
petamoriken
5
1k
when storing skills in S3 file
watany
2
380
My daily life on Ruby
a_matsuda
2
160
2026年のソフトウェア開発を考える(2026/05版) / Software Engineering Scrum Fest Niigata 2026 Edition
twada
PRO
19
9.9k
JOAI2026 1st solution - heron0519 -
heron0519
0
170
ハーネスエンジニアリングにどう向き合うか 〜ルールファイルを超えて開発プロセスを設計する〜 / How to approach harness engineering
rkaga
26
18k
Programming with a DJ Controller — not vibe coding
m_seki
3
750
Import assertionsが消えた日~ECMAScriptの仕様はどう決まり、なぜ覆るのか~
bicstone
2
170
Running Swift without an OS
kishikawakatsumi
0
870
Featured
See All Featured
HTML-Aware ERB: The Path to Reactive Rendering @ RubyCon 2026, Rimini, Italy
marcoroth
1
19
Kristin Tynski - Automating Marketing Tasks With AI
techseoconnect
PRO
0
240
Product Roadmaps are Hard
iamctodd
PRO
55
12k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
28
3.5k
Fireside Chat
paigeccino
42
3.9k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
250
1.3M
Build your cross-platform service in a week with App Engine
jlugia
234
18k
Why Your Marketing Sucks and What You Can Do About It - Sophie Logan
marketingsoph
0
140
エンジニアに許された特別な時間の終わり
watany
106
240k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
122
21k
Principles of Awesome APIs and How to Build Them.
keavy
128
17k
Building AI with AI
inesmontani
PRO
1
960
Transcript
ビルドプロセスをデバッグしよ う! 2025/11/1 Kotlin Fest 2025
自己紹介 HN: マヤミト 本名: 富山雄太 Kotlin Fest運営 DMMでAndroidエンジニアをしています GitHub: https://github.com/yt8492
趣味: Kotlin, Twitter, 同人, 車 Twitter: yt8492
今回のセッションの想定受講対象者 • Kotlin開発中級者以上 • IntelliJ IDEAの基本的な使い方がわかる ◦ 特にDebugger • Gradleの基礎がわかる
◦ 自力でbuild.gradle.ktsなどのビルドスクリプトが書ける • 単純なコンパイルエラー以外のビルド時のエラーで困ったことがある • KMPなどで、ビルド結果(Objective-CやJavaScriptなど)が意図したようにならず に疑問を抱いたことがある
皆さんはこんな経験ありませんか? • Gradleでカスタムのタスクを書いてみたけどうまく動かない • ビルドスクリプトのリファクタリングをして、意図通りに動いているか確かめたい • プロジェクトにGradleプラグインを導入しようとしたらよくわからないエラーが出る • KMPで生成されるコードに納得がいかない
ぼくの実体験 • Gradle Convention Pluginを初めて書いたときに、意図通りに動いているか確か めたかった ◦ (printデバッグでも良かったんだけど、ログを見るのが面倒くさかった ) •
導入したGradleプラグインが自分の意図通りに動かなくて原因を確かめたかった ◦ ビルドエラーにならないのがポイント • KMPでObjective-Cを生成する際に、Kotlinのバージョンを上げるたびにある型 のプロパティ名のsuffixが増減してビルドが通らなくなる問題を改善したかった
• build.gradle.ktsに書いたビルドスクリプト • pluginsで追加したGradleプラグイン • Kotlinコンパイラー これらの挙動は、通常のKotlinプログラムと同じようにIntelliJ IDEAの Debuggerでデバッグできます
ビルドプロセスのデバッグの手順 1. デバッグしたい対象のプロジェクトをIntelliJ IDEA(※1)で開く 2. 目的の処理にブレークポイントを貼る 3. ビルド自体のデバッグを有効にするオプションをtrueにしてGradleタスクを実行す る 4.
IntelliJ IDEAのRemote JVM DebugのDebuggerをAttachする これだけ ※1: Android Studioも含みます
Gradleのビルドプロセスのデバッグを有効にする方法 ./gradlew $task -Dorg.gradle.debug=true • -Dorg.gradle.debug=true でビルドプロセスのデバッグが有効になる • これをデバッグしたいGradleタスクにオプションでつけて実行すると、Debuggerの 接続待機状態になり、Debuggerが接続されるとタスクの実行が始まる
• デフォルトだとポート5005でDebuggerの接続を待ち受けるが、ポートを変更した い場合は -Dorg.gradle.debug.port=5006 のように指定する 参考: https://docs.gradle.org/current/userguide/troubleshooting.html#sec:troubleshooting_build_logic
Gradleのビルドプロセスのデバッグを有効にする方法
デバッグを有効にする際のちょっとしたコツ ./gradlew clean $task -Dorg.gradle.debug=true --no-daemon • 前回のビルドの結果が残っているとビルドのタスクがスキップされることがあるた め、目的のタスクの前にcleanを挟む •
デーモンが有効な状態でデバッグを有効にして実行すると、2回目以降の実行で Debuggerの接続を待ってくれないことがあるため、--no-daemonをつけて実行 する
IntelliJ IDEAのDebuggerの設定 Run -> Edit Configurations… を開く
IntelliJ IDEAのDebuggerの設定 Add New ConfigurationからRemote JVM Debugを選択
IntelliJ IDEAのDebuggerの設定 各種項目はデフォルトのままでOK(タスク起動時にportを指定する場合は変更)
Debuggerを起動する 前述の手順で作成したRemote JVM Debugのconfigurationを選択、通常のアプリ ケーションのデバッグ時と同じようにDebuggerを起動する
いくつかのパターンごとにデバッグのポイントを紹介 1. 自分のプロジェクトのビルドスクリプトをデバッグしたい場合 2. プロジェクトに導入したGradleプラグインをデバッグしたい場合 3. Kotlinコンパイラーをデバッグしたい場合
自分のプロジェクトのデバッグしたい場合 • 手元のIntelliJ IDEAでプロジェクトを開き、通常のアプリケーションのデバッグと同 じように目的の処理にブレークポイントを貼る • プロジェクト内でRemote JVM DebugのConfigurationを作成し、前述の手順でタ スクを起動、Debuggerを起動する
◦ 一番簡単なユースケース ◦ ブレークポイントを貼る場所がアプリケーションコードからビルドスクリプトに変わっただけ ◦ build.gradle.ktsでもbuildSrcやconvention pluginでも同じ
自分のプロジェクトのデバッグしたい場合
自分のプロジェクトのデバッグしたい場合
Gradleプラグインをデバッグしたい場合 • デバッグしたいGradleプラグインのリポジトリをローカルにcloneする • 手元のプロジェクトで利用しているバージョンにgit checkoutする • Gradleプラグインのリポジトリ をIntelliJ IDEAで開き、目的の処理にブレークポイ
ントを貼り、Remote JVM DebugのConfigurationを作成する ◦ 目的のGradleタスクの実装を探す • 手元のプロジェクト のGradleタスクをデバッグを有効にして実行する • Gradleプラグインのリポジトリ のDebuggerを起動する
目的のGradleタスク名でコード検索すると目的の実装を見つけやすいかも Gradleプラグインをデバッグしたい場合
Kotlinコンパイラーをデバッグしたい場合 • Kotlin自体のリポジトリをローカルにcloneする • 手元のプロジェクトで利用しているバージョンにgit checkoutする • Kotlinリポジトリ をIntelliJ IDEAで開き、目的の処理にブレークポイントを貼り、
Remote JVM DebugのConfigurationを作成する ◦ Kotlinコンパイラーの構成を把握していると目的の処理を見つけやすい ▪ おすすめ記事: Kotlinコンパイラの全体像を理解する https://zenn.dev/tommykw/articles/69c64b13d8aec4 • 手元のプロジェクト のGradleタスクをデバッグを有効にして実行する • Kotlinリポジトリ のDebuggerを起動する
Kotlinコンパイラーをデバッグしたい場合
Kotlinコンパイラーをデバッグしたい場合 • たとえばKotlinの定義からObjective-Cのコードを生成する部分をデバッグする場 合、ただブレークポイントを貼るだけだとすべての定義に対して実行が止まってしま う • ブレークポイントの設定で条件を追加して目的の処理だけで止まるようにするなど の工夫が必要 ◦ おすすめ資料:
Debugging: All You Need to Know https://2024.droidkaigi.jp/timetable/694440/
(おさらい)ビルドプロセスのデバッグの手順 1. デバッグしたい対象のプロジェクトをIntelliJ IDEAで開く 2. 目的の処理にブレークポイントを貼る 3. ビルド自体のデバッグを有効にするオプションをtrueにしてGradleタスクを実行す る 4.
IntelliJ IDEAのRemote JVM DebugのDebuggerをAttachする
まとめ • Gradleのビルドプロセスはデバッグできる ◦ 自分のプロジェクトのコードだけでなく、 Gradleプラグインやコンパイラーのコードも ◦ Remote JVM Debug
と -Dorg.gradle.debug=true を使う • デバッグの手法は通常のアプリケーションコードのデバッグと同じ ◦ まずはブレークポイントを貼る場所を決める ◦ 複雑なものはブレークポイントの設定で条件を絞る • 「プラグイン側だから」や「コンパイラー側だから」と諦めず、困ったときにはビルドプ ロセスのデバッグも選択肢として持ってみてください