Nitpicking, but would there be a way to keep the default values in third_party/mavlink/CMakeLists.txt instead of moving them to the superbuild options? So that it stays consistent with the other dependencies and keeps CMakeLists "self-contained".

What do you think?

I tried that initially, however the values did not appear in build/CMakeCache.txt and could not be set from CLI. I suspect it may have to do with calling project again, but unclear. I would prefer that too if it worked.

Fair enough. I'd like to note that - somewhat ironically - this adds some "oddities" to the build system, as the dependency helpers now depend on knowledge that is stored in the superbuild 🙈. But it makes it easier to have a custom dialect, so that's a tradeoff. See how we got there? 😇

If @julianoes is fine with it, that's good for me as well 👍.

I think, I agree with @JonasVautherin. It would be nicer to have these used/defined not just for the SUPERBUILD. Let me try it...

FWIW, here's more details.

If we instead put these variables in the third_party/mavlink/CMakeLists.txt, you will get a cache entry show up in the subproject.

ryan@friedmanr-ubuntu:~/Dev/MAVSDK/build$ grep -Rn MAVSDK_MAVLINK_HASH
third_party/mavlink/CMakeCache.txt:231:MAVSDK_MAVLINK_HASH:STRING=5e3a42b8f3f53038f2779f9f69bd64767b913bb8

Unfortunately, if you try to set this in the top level build command, you cannot; you get this warning.

CMake Warning:
  Manually-specified variables were not used by the project:

    MAVSDK_MAVLINK_URL

If we can find a way to control cache options in subprojects, that would allow us to keep it self contained.
Removing the project command gets rid of that warning, but the cache variable is left as default instead of obeying the command line.

Oh, I see. Thanks for the explanation.

Do you mind fixing the conflict? Then we can merge this.

Done.

Oh dear, this broke CI? 😑

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

@Ryanf55 are you happy with this?

@Ryanf55 are you happy with this?

Looks great, thanks for fixing the broken CI by adding those build flags in!