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
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Yuta Tomiyama
November 01, 2025
Programming
460
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
990
今だからこそ知りたいKotlin Multiplatform
yt8492
0
340
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
CLIであることを活かしたGitHub Copilot CLI活用術 / GitHub Copilot CLI Pro Tips & Tricks
nao_mk2
1
1.1k
UaaL×Androidアプリのメモリ計測 — Memory Profilerの先へ
rio432
0
180
関係性から理解する"同一性"の型用語たち
pvcresin
2
560
AI 時代のソフトウェア設計の学び方
masuda220
PRO
28
9.8k
技術記事、AIに書かせるか、自分で書くか? 〜それでも私が自分の手で書く理由〜 / #QiitaConference
jnchito
2
1.1k
新規プロダクトを高速で生み出すハーネスエンジニアリング
seanchas116
4
310
TypeScriptだけでAIエージェントを作る フロント・エージェント・インフラのフルスタック実践
har1101
6
1k
脅威をエンジニアリングの糧にして――現場編 / Turning Threats into Engineering Fuel — Field Edition
nrslib
0
190
New "Type" system on PicoRuby
pocke
1
200
要はバランスからの卒業 #yumemi_grow
kajitack
0
200
RailsTokyo 2026#4: AI様があれば、 Hotwireの弱点は消えるか?
naofumi
5
990
Talking to terminals (and how they talk back) (KotlinConf 2026)
jakewharton
PRO
1
130
Featured
See All Featured
How GitHub (no longer) Works
holman
316
150k
Leadership Guide Workshop - DevTernity 2021
reverentgeek
1
290
B2B Lead Gen: Tactics, Traps & Triumph
marketingsoph
0
120
Building AI with AI
inesmontani
PRO
1
1k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
830
XXLCSS - How to scale CSS and keep your sanity
sugarenia
250
1.3M
Deep Space Network (abreviated)
tonyrice
0
150
Noah Learner - AI + Me: how we built a GSC Bulk Export data pipeline
techseoconnect
PRO
0
190
Designing Experiences People Love
moore
143
24k
Redefining SEO in the New Era of Traffic Generation
szymonslowik
1
310
Why Our Code Smells
bkeepers
PRO
340
58k
<Decoding/> the Language of Devs - We Love SEO 2024
nikkihalliwell
1
230
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 を使う • デバッグの手法は通常のアプリケーションコードのデバッグと同じ ◦ まずはブレークポイントを貼る場所を決める ◦ 複雑なものはブレークポイントの設定で条件を絞る • 「プラグイン側だから」や「コンパイラー側だから」と諦めず、困ったときにはビルドプ ロセスのデバッグも選択肢として持ってみてください