In a plugin, when writing a C module that uses BSK built-in message types, the plugin's CMakeLists.txt must manually replicate Basilisk's internal GenCMessages logic to generate _C.h / _C.cpp interface files via configure_file. This is necessary because the pre-generated cMsgCInterface/*_C.h headers are not shipped.
This forces to write a foreach/configure_file block that duplicates GenCMessages internals. Is this the intended workflow, or is there a better way I'm missing? If it's intentional, would you consider shipping the headers or a CMake helper?
Proposed fix:
-
Option A: Install the pre-generated *_C.h headers alongside libcMsgCInterface.a into bsk_sdk/include/Basilisk/architecture/messaging/cMsgCInterface/.
-
Option B: Export a bsk_generate_c_msg_interfaces() CMake function from bsk_generate_messages.cmake, wrapping the GenCMessages pattern. Usage would be something like:
bsk_generate_c_msg_interfaces(
MESSAGES AccessMsg AlbedoMsg
OUTPUT_DIR "${CMAKE_CURRENT_BINARY_DIR}/autoSource"
SOURCES_VAR _msg_C_sources
)
In a plugin, when writing a C module that uses BSK built-in message types, the plugin's CMakeLists.txt must manually replicate Basilisk's internal GenCMessages logic to generate _C.h / _C.cpp interface files via configure_file. This is necessary because the pre-generated cMsgCInterface/*_C.h headers are not shipped.
This forces to write a foreach/configure_file block that duplicates GenCMessages internals. Is this the intended workflow, or is there a better way I'm missing? If it's intentional, would you consider shipping the headers or a CMake helper?
Proposed fix:
Option A: Install the pre-generated *_C.h headers alongside libcMsgCInterface.a into bsk_sdk/include/Basilisk/architecture/messaging/cMsgCInterface/.
Option B: Export a bsk_generate_c_msg_interfaces() CMake function from bsk_generate_messages.cmake, wrapping the GenCMessages pattern. Usage would be something like: