Over time I made a few changes unrelated to what I'm really working on.
These changes are hereby committed first. The bug fixes are related to
what I'm doing in that I need them to be fixed for future commits.
Tools/sitl_run.sh: rename label to rcS_dir and fix usage help.
cmake/common/px4_base.cmake: Remove the check on OUT_UNPARSED_ARGUMENTS,
and a few typos and indentation issues.
cmake/configs/posix_sitl_replay.cmake: Set the correct variable
(config_sitl_rcS_dir) to the correct directory.
cmake/nuttx/px4_impl_nuttx.cmake: typos and indentation issues,
and removal of a redundant FORCE (INTERNAL implies FORCE).
cmake/posix/px4_impl_posix.cmake: typos and indentation issues.
cmake/qurt/px4_impl_qurt.cmake: typos and indentation issues.
src/modules/mavlink/mavlink_ftp.cpp : possible strict-aliasing breakage.
NOTES
The second argument passed to sitl_run.sh is the value of
config_sitl_rcS_dir. This fact is missing from the usage help.
I renamed 'label' to 'rcS_dir' to better reflect this.
Also, for the 'replay' config the wrong variable was set causing
the call to sitl_run.sh to skip an argument and fail (ie the
debugger was passed as rcS_dir and so on).
The check on OUT_UNPARSED_ARGUMENTS in px4_parse_function_args
basically causes every passed IN variable to be REQUIRED and is
therefore a bug. The test for the presence of the REQUIRED arguments
follows directly after and is sufficient for this job. This bug went
unnoticed because currently every argument to OPTIONS, ONE_VALUE,
and MULTI_VALUE is actually passed to the function(s) calling
px4_parse_function_args (them being REQUIRED or not).
The changes in mavlink_ftp.cpp are to avoid a possible aliasing bug
and (mostly) to avoid the compiler warning/error: dereferencing type-
punned pointer will break strict-aliasing rules [-Werror=strict-aliasing].
GCC 6.1.1 output:
../src/modules/fw_att_control/fw_att_control_main.cpp:884:41: error:
implicit conversion from ‘float’ to ‘double’ to match other operand of
binary expression [-Werror=double-promotion]
It is useful to run jmavsim separately, for example when debugging mainapp
separately, or running some other external tool on mainapp (like heap
analysis)