clang can be verbose with warnings, but some of it is probably valid when building a 64bit binary.
Highlighted changes:
* Call float versions of math functions to avoid conversion to double by the compiler (absf, sqrtf, roundf, etc)
* Make sure floating point constants are marked as floats, to avoid conversion to double by the compiler. (1.0 is a double, 1.0f is a float and when doing math between float and double, all values get upgraded to double!)
* Changed memcpy_fn in unit test AND SITL builds to be a macro to memcpy (instead of inline function calling memcpy), this fixes linker errors for memcpy as macos compiler mangles the symbol in a different way and would not work with asm("memcpy") call.
* Some simulator code made heavy use of doubles, but since all the data in INAV is float, that is probably overkill and some functions/macros had float in the name, while upconvertting to double.
Open questions:
* Should scale in osdFormatCentiNumber be changed to float? It is currently uint32_t but some of the scale defines are, correctly, not integer numbers.
* I changed CENTIDEGREES_TO_DEGREES to use float on the division path, but the code seems to be ok, or assuming it would be converted to integer anyway. Is this the correct solution?
* This still does not fix the invalid settings issues, I suspect it is related to the lack of linker scripts in clang, to preserve the section data of settings.
* Binary is still not multi platform (arm/x86_64).
Clean up cmake files for SITL and fix the compilation issues caused by tooling differences between gcc and clang (used in MacOSX).
SITL on MacOSX still has lots of compile time warnings that need to be addressed and some known issues that prevent it from working with simulators, but those will be addressed in 7.0.
At this point, I don't think MacOSX SITL is ready to be added to the configurator. That should be targeted for 7.0.
Co-Authored-By: EMSR <10240646+shanggl@users.noreply.github.com>
Co-Authored-By: carl <101383042+tcdddd@users.noreply.github.com>
Co-Authored-By: Hugo Chiang <hugo@gyroflow.xyz>