ut-issl / c2a-core

Satellite Flight Software: Command-Centric Architecture
MIT License
51 stars 11 forks source link

user 側で実装すべき関数の宣言のかかれたヘッダーを user が持つのではなく, core から提供したい #553

Open meltingrabbit opened 1 year ago

meltingrabbit commented 1 year ago

概要

user 側で実装すべき関数の宣言のかかれたヘッダーを user が持つのではなく, core から提供したい

詳細

例えば,

は,core から呼び出される関数で,すべての user が実装している. こういうものは

と,宣言と定義が .h, .c に分かれて,同じフォルダ(=ともに user)に存在している.

ヘッダーは core でもちたい?

close条件

方針決めて実装したら

meltingrabbit commented 1 year ago

@sksat これ,core に移動するとして,core のどのディレクトリに配置するのがいいんだろうか?

上の例だと, src/src_core/TlmCmd/user_packet_handler.h とか? それとも,こういうたぐい,全部まとめて src/src_core/include/TlmCmd/user_packet_handler.h みたいな感じにする?

sksat commented 1 year ago

include みたいなディレクトリは c2a-core にあるすべてのヘッダをそこに移すのでなければ混乱しか生まないのでやめた方がいい

sksat commented 1 year ago

これこそ真に並列してる概念なんだから並列してる c2a-core のディレクトリにいればよくない?(つまり,src_core/TlmCmd/ 以下でよくない?) あんまり何をどう悩んでるかがわかってないかも.

meltingrabbit commented 1 year ago

なんか,userが実装すべき関数一覧,ぱっとわからないけど,いいのかな,って.

sksat commented 1 year ago

そもそも "c2a-core" というのはライブラリの単位としては一切正しくなくて,ライブラリとして扱うべきは src_core/TlmCmd とかの単位(実運用上そういかないとしても,そのように扱い設計すべき)なので,その中で明らかになっていればよいと思う(そのため,将来的に src_core/TlmCmd/include が生える,とかはナシではないかな). src_core/include みたいなのは "c2a-core" という単位でのリリースをバラしにくくする割には得られるうまみがそこまでないと思う.

sksat commented 1 year ago

user が実装すべき関数一覧はなんも実装せずに executable build したらリンクエラーで得られるみたいな雑な見方もあるし,なんらかの明示的な指定をするとしても documentation comment とかでよいのではないか(現状の Doxygen でもなんか共通したコメント足すぐらいで一覧は得られるのでは?)