`src_core` をなんとかしたい

[meltingrabbit]

概要

src_core をなんとかしたい

詳細

src/
  src_core/
  src_user/

という構造が適切ではないので，なんとかしたい．

close条件

なんとかなったら

備考

NA

[meltingrabbit]

議論点

• src_core → c2a_core とか？
• src_user → ？？？？

うーん，，，

coreとuserの分離的な観点だと，並行なディレクトリ構造があって，共通部分とそうでない部分を並列させているだけなので．．．

[sksat]

以下のような手順での src/src_core, src/src_user の廃止を検討中です．意見求む． PHASE 分割して書いたけど，それぞれ結構 breaking なので実際のリリース時にはある程度マージしてやってもよいと思う．

• PHASE 1
  • out-of c2a-core build の導入
    • Git submodule でない外部ディレクトリにある c2a-core を使用可能にする
    • 注意: c2a-core は src_core という名前で checkout されていることを期待する
    • これに対応するため，C2A user では #include "../../src_core" などを全排除する必要がある（割と残っていがち）
  • C2A_CORE_SRC_DIR を追加
  • C2A_CORE_DIR は ${C2A_CORE_SRC_DIR}/src_core とする
  • include dir として C2A_CORE_SRC_DIR を追加
• PHASE 2
  • src_core を c2a-core にすべて rename する
    • out-of c2a-core build 時には c2a-core が c2a-core という名前で checkout されていることを期待する
  • C2A_CORE_DIR は ${C2A_CORE_SRC_DIR}/c2a-core とする
  • ディレクトリ構造は以下
    • src
      • c2a-core: Git submodule
      • src_user: ユーザー部のコード
• PHASE 3
  • include dir として repository root を追加
  • <repo>/src/c2a-core -> <repo>/c2a-core
    • #include <src/c2a-core/hoge.h> -> #include <c2a-core/hoge.h>
  • ディレクトリ構造は以下
    • c2a-core: Git submodule
    • src
      • src_user: ユーザー部のコード
• PHASE 4
  • <repo>/src/src_user -> <repo>/src
  • #include <src/src_user/hoge.h> -> #include <hoge.h>
  • ディレクトリ構造は以下
    • c2a-core: Git submodule
    • src: ユーザー部のコード

[meltingrabbit]

全体的に agree

include dir として C2A_CORE_DIR を追加

#include <c2a-core/hoge.h> だから，inclulde dirは C2A_CORE_SRC_DIR ？

out-of c2a-core build 時

ってなんだっけ？

#include <src/c2a-core/hoge.h> #include <src/src_user/hoge.h>

これいまあるっけ？（ない想定のはず）

あと

• core から user の include どうする？
• 今， #include <src_core/hoge> #include <src_user/hoge> が対称（coreとuserのディレクトリ構造が相同）だけど，user側はそれをなくす，という感じだよね？（まあ特にここは気持ちはないのでOK）

[sksat]

typo してたんで edit しました > C2A_CORE_DIR

言葉不足だったけど，大文字の C2A_CORE_SRC_DIR とかは CMake の変数の話で，それがコンパイラからどう見えるかは別．これの場合だと，C2A_CORE_SRC_DIR が include path なので，その下にいる c2a-core が include 時に参照できる，という話．

out-of c2a-core build は僕が最近作った（僕しか使ってない）造語で，「（Git submodule でない）外部ディレクトリにある c2a-core を使用可能にする」に名前を付けたもの > out-of c2a-core build

それはその PHASE 時点で発生するものの話 > #include <src/c2a-core/hoge.h>

[meltingrabbit]

OK

[sksat]

core から user への include はあんまりちゃんと考えてなかった......（そもそもあってほしくないのだけど，まあ仕方ない）

とはいえ，それもユーザ部のコードが入ってるディレクトリ（今でいう src/src_user）から直接参照してほしいかなあ．つまり，core 部でも #include <src/src_user/hoge.h> が hoge.h になる． ここで問題となるのが，core と user のソースファイル配置を対照的にしようとしていたことによって src/src_core/hoge.h と src/src_user/hoge.h みたいなやつが同時に存在していると（してそう）include path の優先順位問題が発生してしまうこと． ただ，これはそもそも対照的にしようとしているのがおかしいと思う（ライブラリやコンポーネントみたいな単位での対称さはあってよいと思うけど，ファイル名でそれをやるのはおかしいはず）ので，ユーザ側の方のファイルには _user みたいな suffix を付けるべきなのでは．

[meltingrabbit]

あ，ファイル名が全く同じ ヘッダファイルはないよ（インクルードガード命名規則に反するので）

userが独自に作ってたら知らないけど

[meltingrabbit]

対称的にしてる，ライブラリとしては変なのはわかっていつつも，LibraryやApplicationなどは，汎用的なもの（ここでの汎用，とは，多くの衛星FSWでもっていてよい，という意味での汎用であって，SW的汎用ではない）をcoreにいれていく，という経緯から，対称的なほうがわかりやすい，というのがあったなぁ．

[sksat]

user が勝手に作ってた場合のことを考えてました（そして治安の悪い user はそこそこありそうだし）． でも include gurad の規則に反するのはたしかに．そうすると実際にはほぼ存在してなさそうだな．

[sksat]

Library と Application については，そもそも「（core の || user の）Library」，「（core の || user の）Application」という単位で命名・ビルドしていることがおかしいな，という気持ちがあるので，そこの単なるディレクトリの場所の対称関係は崩していいと思っています．

[sksat]

微妙に伝わりにくいと思うのでもうちょっと具体的に言うと，汎用的（であるべき）なのは c2a-core/Library ではなく c2a-core/Library/crc とかじゃないですか，みたいな気持ち．

[sksat]

たぶん一番気持ちがあるので，self assign

[sksat]

自動生成コード中に #include "../../src_core" が残ってるのと， git_revision.sh をどうにかする必要がある．

[sksat]

git_revision は根本的解決をすべきなので， #82 を復活させる

[meltingrabbit]

#82 の復活ありがたい．

[meltingrabbit]

Library と Application については，そもそも「（core の || user の）Library」，「（core の || user の）Application」という単位で命名・ビルドしていることがおかしいな，という気持ちがあるので，そこの単なるディレクトリの場所の対称関係は崩していいと思っています．

OK． そうなってくると，いよいよ

• https://github.com/ut-issl/c2a-core/issues/553

をなとかしたさはあるな

[sksat]

#553 はとりあえずエイヤで c2a-core に場所移してから考えればよくない？（あんまり src_core 問題とは依存関係無いと思う）． 明らかにビルド単位がおかしいのは Library と Application だけだし，この２つは割と自明に分割可能じゃない？という気もするし（Application は Application そのもののインターフェースを定義するヘッダみたいなやつは生えるかもだけど）．