Fix mavros_node loading and component loading.
But looks like UAS needs extra debugging when used that way.

Fix for moved mavlink messages in 2025.9.9. Unfortunately cmake's check_cxx_symbol_exists() do not work for it, and mavlink do not have version variable (unsure why, though ament reads package.xml).

and mavlink do not have version variable (unsure why, though ament reads package.xml).

Mavlink does yet not generate a CMake-compatible version file.
I just compiled ros2-gbp/mavlink-gbp-release on release/humble/mavlink/2025.9.9-1 to see.
Check install/mavlink/share/mavlink/cmake/mavlink-config.cmake and notice how it doesn't include anything related to versioning. Just because the version is set in the package.xml doesn't mean it's usable.
That needs more CMake code added.

@vooon FYI MAVLink is planning on moving as much of the stuff in common.xml as is actually common into standard.xml. This is going to be a slow process, and is likely to break you again.
Note that we didn't even consider this since most C systems include common/mavlink.h which picks up all the other definitions.

This is going to happen but I'm open to suggestions on how we can mitigate the pain to you.

@hamishwillee cmake has the capability to check defined symbols for C/C++, probably i just need to get it working.

Or maybe to change C++11 mavgen to make cross-namespace 'using' (but i don't really like that idea).

@hamishwillee cmake has the capability to check defined symbols for C/C++, probably i just need to get it working.

Or maybe to change C++11 mavgen to make cross-namespace 'using' (but i don't really like that idea).

If you can restrain it to class scope rather than polluting the global namespace with mavlink symbols, that's probably fine.

@vooon FYI MAVLink is planning on moving as much of the stuff in common.xml as is actually common into standard.xml. This is going to be a slow process, and is likely to break you again. Note that we didn't even consider this since most C systems include common/mavlink.h which picks up all the other definitions.

This is going to happen but I'm open to suggestions on how we can mitigate the pain to you.

If moving messages causes public ABI breaking changes in the generated code, perhaps we should wait on moving messages until we have a better way to support not breaking users?