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

[meltingrabbit]

概要

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

詳細

例えば，

• c2a-core/Examples/minimum_user/src/src_user/TlmCmd/user_packet_handler.h

  Line 40 in afd6ee3

  PH_ACK PH_user_analyze_cmd(const CommonCmdPacket* packet);

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

• src/src_user/TlmCmd/user_packet_handler.c
• src/src_user/TlmCmd/user_packet_handler.h

と，宣言と定義が .h, .c に分かれて，同じフォルダ（＝ともに user）に存在している．

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

close条件

方針決めて実装したら

[meltingrabbit]

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

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

[sksat]

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

[sksat]

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

[meltingrabbit]

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

[sksat]

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

[sksat]

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