Each library in ardupilot is a folder with the source in. That avoids build
failures when there are files in libraries/. That fixes#4099 ("waf doesn't
seem to like TAGS files") and #4093 ("sim_vehicle.py /w waf /w eclipse project
broken on Cygwin").
That problem can be reproduced by just creating a file in libraries/ and trying
to build with waf.
There should be a better way to confirm a path is an ardupilot library. That
can be done later.
When trying to execute sim_vehicle.py this is the current output:
Warning: Could not find '../Tools/autotest/../../ArduCopter/../build/sitl/bin/arducopter-quad',
starting '/bin/bash' instead. Please check your profile settings.
Fix the path to the binary and use absolute paths to ease the debug.
Add noreturn attribute to field_not_found(). This function always call
abort() if the field was not found. The compiler may not know about it
and may think some variables are used uninitialized:
../../Tools/Replay/LR_MsgHandler.cpp: In member function ‘void LR_MsgHandler_GPA_Base::update_from_msg_gpa(uint8_t, uint8_t*)’:
../../Tools/Replay/LR_MsgHandler.cpp:212:24: error: ‘sacc’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
gps.setHIL_Accuracy(gps_offset, vdop*0.01f, hacc*0.01f, vacc*0.01f, sacc*0.01f, have_vertical_velocity, sample_ms);
^
Instead of just initializing the variable (which is pointless in this case),
teach the compiler that this function never returns so require_field() works
properly.
This is a hackish way to allow waf running on windows. In some
combinations of the tools the python interpreter seems to be crashing on
windows:
Found 180 MAVLink message types in 2 XML files
Generating C implementation in directory /tmp/ArduPlane.build/libraries/GCS_MAVLink/include/mavlink/v1.0/ardupilotmega
Generating C implementation in directory /tmp/ArduPlane.build/libraries/GCS_MAVLink/include/mavlink/v1.0/common
Copying fixed headers
last line in mavgen.py
Aborted (core dumped)
michael@WIN-3NBOUTHN4TN /cygdrive/c/Users/michael/Desktop/DIYDrones/ardupilot/ArduPlane
$ echo $?
134
Here we check the return code to be greater than 128 since that means the
interpreter received a signal. In this case we clear the return code.
sim_vehicle.py: choose default waf_target based on specified vehicle
sim_vehicle.py: add --no-rebuild-on-failure option
sim_vehicle.py: make help clearer by adding option groups
sim_vehicle.py: improve output of executed commands
Emit something that could be copy-and-pasted into a shell
sim_vehicle.py: allow specification of multiple gdb breakpoints
sim_vehicle.py: understand some specific mavproxy options
sim_vehicle.py: validate vehicle, throw warning if it looks suspect
sim_vehicle.py: avoid use of psutil (cygwin not supported)
sim_vehicle.py: rename build_target to make_target
sim_vehicle.py: pass vehicle binary to start_vehicle
sim_vehicle.py: waf build system support
sim_vehicle.py: use waf by default
../../Tools/CPUInfo/CPUInfo.cpp:21:54: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat=]
hal.console->printf("char : %d\n", sizeof(char));
^
And so on.
Ideally for sizeof() which returns size_t we would use %zu, but that's not
implemented by our version of printf. So use %lu which should be ok in all of
our boards.
Fix warnings like this:
<command-line>:0:21: warning: "APM_BUILD_DataFlash_test" is not defined [-Wundef]
/home/lucas/p/dronecode/ardupilot/libraries/AP_Vehicle/AP_Vehicle_Type.h:36:41: note: in expansion of macro ‘APM_BUILD_DIRECTORY’
#define APM_BUILD_TYPE(type) ((type) == APM_BUILD_DIRECTORY)
^
These happen because we are trying to set APM_BUILD_DIRECTORY to undefined
values. We should rather default to the APM_BUILD_DIRECTORY ==
APM_BUILD_UNKNOWN
check for the presence of libiio to enable the compilation of
the bebop rangefinder that needs it.
If the build remains static, there needs to be a rootfs that contains
the libiio.a file because it is not included in the debian package.
A solution can be to compile libiio and copy libiio.a in /usr/lib[/arch]
Otherwise it fails to link:
[335/335] Linking build/sitl/bin/arducopter-quad.exe
ArduCopter/libArduCopter_libs.a(SIM_Aircraft.cpp.4.o):SIM_Aircraft.cpp:(.text$_ZN4SITL8AircraftC2EPKcS2_+0x230): undefined reference to `_imp__timeGetTime@0'
ArduCopter/libArduCopter_libs.a(SIM_Aircraft.cpp.4.o):SIM_Aircraft.cpp:(.text$_ZN4SITL8Aircraft16setup_frame_timeEff+0x9f): undefined reference to `_imp__timeGetTime@0'
ArduCopter/libArduCopter_libs.a(SIM_Aircraft.cpp.4.o):SIM_Aircraft.cpp:(.text$_ZN4SITL8Aircraft16setup_frame_timeEff+0x125): undefined reference to `_imp__timeGetTime@0'
ArduCopter/libArduCopter_libs.a(SIM_Aircraft.cpp.4.o):SIM_Aircraft.cpp:(.text$_ZN4SITL8Aircraft15sync_frame_timeEv+0x21): undefined reference to `_imp__timeGetTime@0'
ArduCopter/libArduCopter_libs.a(SIM_Aircraft.cpp.4.o):SIM_Aircraft.cpp:(.text$_ZN4SITL8Aircraft15sync_frame_timeEv+0x152): undefined reference to `_imp__timeGetTime@0'
ArduCopter/libArduCopter_libs.a(SIM_Aircraft.cpp.4.o):SIM_Aircraft.cpp:(.text$_ZNK4SITL8Aircraft16get_wall_time_usEv+0xe): more undefined references to `_imp__timeGetTime@0' follow
collect2: error: ld returned 1 exit status
Since we escape $PATH, we can't just try to export that way. Since PATH
is unset if we do this, we end up with things like :
./Tools/scripts/install-prereqs-ubuntu.sh: line 101: apt-cache: command
not found
If we are running the script, we are likely inside the repository, in
which case the script would fail while searching for a directory named
ardupilot. Derive the root directory from the script location.
ubuntu@ubuntu-xenial:~/ardupilot$ ./Tools/scripts/install-prereqs-ubuntu.sh
./Tools/scripts/install-prereqs-ubuntu.sh: line 19: python-wxgtk3.0: command not found
While at each, change to use lsb_release like the other scripts.
