I think this creates a hard dependency on the superbuild. Maybe it would be worth having the path as an option, e.g. MAVLINK_MSG_DEFINITIONS_PATH, and the superbuild would by default set it to ${DEPS_INSTALL_PATH}/include/mavlink or something?

I thought that too but then it worked in CI...

I like the name, libmavlike 😬

I might rename my fork as well.

I am always nervous with add_custom_command. CMake is really not a super nice scripting language, and those always look cryptic to me. It took me way longer than I'm comfortable with to realise that this really just creates one header file called embedded_mavlink_xml.h that gets included later and that doesn't change unless we update the mavlink dependency.

The risk I see is going the road of the PX4 build system, which is so custom that I don't consider it to be CMake anymore, and it is always painful for me to read/use.

What about doing it like we do for the proto files, i.e. generate it once and version it? Just like you only need to run generate_from_protos.sh when you modify the protos, you would only have to run generate_embedded_mavlink.sh when you modify mavlink. And nobody should ever have to do it except those who update libmavlink in MAVSDK (so... pretty much the maintainers).

So that it keeps the CMakeLists readable, and I'm pretty sure that a shell script would be a lot more readable than this custom command 🙈.

What do you think?

I agree in terms of readability but would you then check the generated header file in, or generate it each time?

I would check it in, like we do with the protobuf files. Maybe in a generated/ folder, to be consistent?

We could do that but I want to make it easy for users to swap this out as well. I guess we can make it, so you need to load "common" manually before using it.

I thought, a script like ./tools/generate_mavlink_direct.sh that would generate the file and put it in the right place (something/generated/mavlink_embedded_headers.h). And that file is versioned. So that it doesn't require a change in the CMakeLists (except for installing the header), users don't have to care about it but they can always update libmavlink and regenerate the file with the ./tools/generate_mavlink_direct.sh script.

Exactly like we do now with the proto files.

Or does that sound to complicated?

I'm somewhat tempted to leave it as is because it has the advantage that the MAVLink version included will match the one from the headers, and if someone changes the C headers, both change accordingly, and don't get out of sync.

Sure, your call. I'm just always nervous when I see add_custom_command in CMake, but I guess it won't go as far as in did in PX4 anyway 🙈.