Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
ビルドプロセスをデバッグしよう!
Search
Yuta Tomiyama
November 01, 2025
Programming
520
2
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
ビルドプロセスをデバッグしよう!
2025/11/1 Kotlin Fest 2025 にて発表
Yuta Tomiyama
November 01, 2025
More Decks by Yuta Tomiyama
See All by Yuta Tomiyama
モバイルアプリ開発を始めよう!
yt8492
0
130
Git勉強会
yt8492
0
240
なんでもやってみる勇気
yt8492
0
140
Android Autoが思ったよりしんどい話
yt8492
0
260
apollo-kotlinにcontributeした話
yt8492
0
210
DMM TVのSDカードダウンロード機能を実装した話
yt8492
1
1.1k
今だからこそ知りたいKotlin Multiplatform
yt8492
0
360
State management and API calls in Jetpack Compose: Learning Apollo + Jetpack Compose through React Hooks
yt8492
0
1.4k
サーバーフレームワークの仕組みが気になったので車輪の再発明をしてみた
yt8492
0
270
Other Decks in Programming
See All in Programming
Kotlinの15年とServer-Side Kotlin
n_takehata
1
170
AI時代のIaC入門 〜なぜインフラをコードで管理したいのか?〜 / Introduction to IaC in the AI Era
akihisaikeda
5
1.3k
コーディング自動化の次へ。人の介入をゼロにするファクトリーとサポートAIによる実践
timakin
5
4.9k
[JA] Domain Modeling with Vanilla Rails: 「操作」から再考するRailsの設計論
yasaichi
4
1.4k
flutter_test のその先へ — Flutter アプリの LLM 機能に「評価」という品質保証を
kosukesaigusa
0
140
Spec-Driven Development - Why Vaadin Is the Perfect Fit
simas
PRO
0
190
動画プレイヤーはなぜカクつくのか 〜Flutterのレンダリングとネイティブの境界を解剖する〜
naruogram
0
310
AI時代のシニアエンジニアとは
yosuke_furukawa
PRO
12
11k
golang-bob.pdf
iwatsukayura
0
150
dotNET_vulnclicker_intro.pdf
deka_morita
0
160
現場と育てるRailsモデリング 〜Spreadsheetから始めたモデル設計〜
siroemk
2
1.1k
自作Discord音声botをLambda MicroVMsに移行した話 / Migrating My Discord Voice Bot to Lambda MicroVMs
akihisaikeda
0
190
Featured
See All Featured
The Anti-SEO Checklist Checklist. Pubcon Cyber Week
ryanjones
0
290
A Soul's Torment
seathinner
8
3.9k
Typedesign – Prime Four
hannesfritz
42
3.2k
Effective software design: The role of men in debugging patriarchy in IT @ Voxxed Days AMS
baasie
1
590
Optimising Largest Contentful Paint
csswizardry
37
4k
Future Trends and Review - Lecture 12 - Web Technologies (1019888BNR)
signer
PRO
0
3.8k
BBQ
matthewcrist
90
10k
Odyssey Design
rkendrick25
PRO
2
900
Deep Space Network (abreviated)
tonyrice
0
390
Jess Joyce - The Pitfalls of Following Frameworks
techseoconnect
PRO
1
460
Crafting Experiences
bethany
1
400
Building Flexible Design Systems
yeseniaperezcruz
330
41k
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 を使う • デバッグの手法は通常のアプリケーションコードのデバッグと同じ ◦ まずはブレークポイントを貼る場所を決める ◦ 複雑なものはブレークポイントの設定で条件を絞る • 「プラグイン側だから」や「コンパイラー側だから」と諦めず、困ったときにはビルドプ ロセスのデバッグも選択肢として持ってみてください