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
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Yuta Tomiyama
November 01, 2025
Programming
1
390
ビルドプロセスをデバッグしよう!
2025/11/1 Kotlin Fest 2025 にて発表
Yuta Tomiyama
November 01, 2025
Tweet
Share
More Decks by Yuta Tomiyama
See All by Yuta Tomiyama
モバイルアプリ開発を始めよう!
yt8492
0
87
Git勉強会
yt8492
0
180
なんでもやってみる勇気
yt8492
0
120
Android Autoが思ったよりしんどい話
yt8492
0
230
apollo-kotlinにcontributeした話
yt8492
0
160
DMM TVのSDカードダウンロード機能を実装した話
yt8492
1
910
今だからこそ知りたいKotlin Multiplatform
yt8492
0
310
State management and API calls in Jetpack Compose: Learning Apollo + Jetpack Compose through React Hooks
yt8492
0
1.3k
サーバーフレームワークの仕組みが気になったので車輪の再発明をしてみた
yt8492
0
220
Other Decks in Programming
See All in Programming
CSC307 Lecture 09
javiergs
PRO
1
840
HTTPプロトコル正しく理解していますか? 〜かわいい猫と共に学ぼう。ฅ^•ω•^ฅ ニャ〜
hekuchan
2
690
Honoを使ったリモートMCPサーバでAIツールとの連携を加速させる!
tosuri13
1
180
Oxlint JS plugins
kazupon
1
980
QAフローを最適化し、品質水準を満たしながらリリースまでの期間を最短化する #RSGT2026
shibayu36
2
4.4k
React 19でつくる「気持ちいいUI」- 楽観的UIのすすめ
himorishige
11
7.5k
AIと一緒にレガシーに向き合ってみた
nyafunta9858
0
250
Claude Codeと2つの巻き戻し戦略 / Two Rewind Strategies with Claude Code
fruitriin
0
140
AI巻き込み型コードレビューのススメ
nealle
2
650
Amazon Bedrockを活用したRAGの品質管理パイプライン構築
tosuri13
5
770
副作用をどこに置くか問題:オブジェクト指向で整理する設計判断ツリー
koxya
1
610
MUSUBIXとは
nahisaho
0
140
Featured
See All Featured
WENDY [Excerpt]
tessaabrams
9
36k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
54k
Become a Pro
speakerdeck
PRO
31
5.8k
How GitHub (no longer) Works
holman
316
140k
Technical Leadership for Architectural Decision Making
baasie
2
250
Lightning talk: Run Django tests with GitHub Actions
sabderemane
0
120
The Curious Case for Waylosing
cassininazir
0
240
Building a Scalable Design System with Sketch
lauravandoore
463
34k
Navigating the moral maze — ethical principles for Al-driven product design
skipperchong
2
250
Utilizing Notion as your number one productivity tool
mfonobong
3
220
Mobile First: as difficult as doing things right
swwweet
225
10k
Building Experiences: Design Systems, User Experience, and Full Site Editing
marktimemedia
0
410
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 を使う • デバッグの手法は通常のアプリケーションコードのデバッグと同じ ◦ まずはブレークポイントを貼る場所を決める ◦ 複雑なものはブレークポイントの設定で条件を絞る • 「プラグイン側だから」や「コンパイラー側だから」と諦めず、困ったときにはビルドプ ロセスのデバッグも選択肢として持ってみてください