【Console Application】外部関数 19【学習記】

いわゆる include よー🤤

Q.
それで import できたの？
A.
それが import できなかったの😞

→今の段階では諦めて JAR で行く事に🙄
→別プロジェクトを取り込んで使う設定は入門者には無理だった😞

#IntelliJ #Kotlin #import
#Gradle
#学習記

最後の悪あがき

それじゃ、引き続き import よー🤤

Gradle プロジェクト
https://pleiades.io/help/idea/work-with-gradle-projects.html

多分、最も信頼すべき資料😞
gradle を理解できていればここを読めば「ああ、こうやるのね」ってなる資料に仕上がってると思う☺️

と思う…つまり、初心者には「資料は有るがこれでは目的を達成できない」ってやつね🙄
見ていると C に有るパスを追加するような手合の設定もちゃんとあるのが判るけれど IntelliJ の拵こしらえるプロジェクトは複雑な階層構造知ってる人が見れば良く整理された分類郡になっていて「役割は判るけど、指定の是非もどれが指定の対象となるのかも判らない🙄」物になってしまってるのよね😞
ヒントって、知っているのが前提のシロモノなのだわさ🙄
MDNMozilla Developper Netowork の資料が優秀なのは「参考例」が大きい事が挙げられると思う🤤
Gradle や IntelliJ の資料は適用範囲の狭い参考だけを用意していて「つまり全体ではどうすると使える様になるの？」という資料が欠落している状態なのかなと感じる🙄
つまり、公式資料の精度が悪い…🤔
サンプルが多ければ良いわけではないけれど、辞書や IT での公式文章は「例文」の多さが評価の一部になっているところを考えると、長い事開発しているにも関わらず片手落ちな資料しか無いと言わざるを得ないかしら🤪
IDE は GUI で使いやすくしましょうという理念で作られる筈なのに「取り込みは GUI 的な動作はするけど設定は自分で調べて手で追加してね☺️にっこり」は些いささか「最新」と銘打ってる事に疑問符が付く😞

…

…

…

サブプロジェクト？

マルチプロジェクトじゃなくてサブプロジェクトで引いてみようかな🤤

Gradle で Single-Project から Multi-Project への変換
https://nisenabe.hatenablog.com/entry/2020/06/03/215929

やっぱりこの記事が出てくる🤤
前までは流し読みだったけどちょっとじっくり読んだらこの記事は「シングルに別プロジェクトを読み込んでマルチ化」しているのではなく「シングルに階層を生成して(実際はシングルのファイル郡のままだけど)構造的にマルチ化」している記事だった模様🙄
これだと別プロジェクトを取り込みやすくなるのかな？良くわからない🤪
一先ず求めてる解はここでは得られないというのが判る😞(ヒントにはなる様だけど

Gradleで複数サブプロジェクトをもつプロジェクトを作成する
https://kdnakt.hatenablog.com/entry/2021/06/18/gradle-multi-projects-build

前回までに何度か見ている記事だけど、最初に纏めてサブプロジェクトを作る記事なんで参考からは除外していたのよねこれ🤔
勿論もちろん今回も除外なんだけど出てこないので「これは違う」って話で載せる🤪(ｺﾗ

…

…

…

後は質問掲示板とか、催事の記録とか、 Spring とか、自分の記事とか…

調　　査

終　　了

(画像の出典:進撃の巨人/講談社)

allProjects

最後の悪あがき🤪
allProjects で適当にちょっと囲んでみようの巻🤤

赤表示だらけ😞ﾃﾞｽﾖﾈｰ

考察

知ってる人からしたら当てずっぽうな話かもしれないけどヨソのプロジェクトを取り込んで使うには、という考察を置いとく😞(備忘録的な

調べた感じではヨソからソースごとプロジェクトを取り込んで使うのは「マルチプロジェクト」という状態になるというのは判ったんだけどただインポートしてもうまくいかないのよね🙄
この「うまくいかない」はプログラム初心者の「うまくいかない」であって、蓄積が無いので「何がどう良くないのか」を導き出せず「分からない事だけは分かる」という状態😞
GUI なんだからインポートしたらアプリ側が勝手に良さげに調整してくれるもんと思っていたら取り込むだけで何もしてくれないっていう…そこまでは判っても初心者にはどうもできない🙄

このマルチプロジェクトの状態だとインポートしたプロジェクトの build.gradle で使ってる物が mainroot とぶつかるんだけどこれを main の build.gradle で回避するなり統合するなりの記述が要るらしい…ってのは判ったけど具体的な書き方は探しても全く出てこない😞

JAR を取り込む時もそうだったけれど main のファイル郡を保存している階層下に持ってこないといけないのかな？という感じがしていたんだけど、大規模開発だとそんな状態には絶対なってない筈なのよね🤔
main と、別で開発されているモジュールは完全に別の階層、ヘタするとネット越し、もあり得るから、今回違う階層のままでできないかずっと探ってたけどだめっぽ😞
ヨソで開発してたソース付きを「参照可能」にして「まとめてビルド」は C では常套手段の筈で、最新のビルド環境の Gradle ができるようになってないとは考えにくいのでずっと main には移動しなかったというのが真相だけど欲張り過ぎたのかな…そんな筈は無いと思うんだけど…🙄

setting.gradle に書く include と project().projectDir も IntelliJ 的には赤表示Errorになってなかったけれどコンパイル段階では恐らく正しくない記述になってたのかなと思う🤔
正しく書けていたら main.kt の import も Unresolved になっていないし、⌘クリックでジャンプできていただろうなと思う😞

setting.gradle と build.gradle の記述双方で不足がありまくりでできなかったという事は確かだけど正解が元々分からないので探しようも無かったのが今回の敗因なのかなと思う🙄

誰かが「天才の1行は100行で動く」等と言ってたけれど、これはどんなに頑張って行数増やしても動かないものは動かないから是非こういうのにぶち当たって発狂して欲しいものだ🤪

とりあえず JAR を取り込んで使う、でヨシとする事にした…

ところで JAR の関数を赤くしないのはどうやるの…？🤪

次回は

Objective-C で「ライブラリ化した外部関数」の取り込みをやろうかな🤤
実は dylibwindowsで言うDLL の参照とかやった事ないので試したい🤪