That makes more sense, since that module is supposed to have basic Ardupilot
specific features. The root wscript should be a mere user of those features.
This approach is better then the previous one mainly because the latter
required creating the task generator for the checks in a separate group and
posting that target implied in posting the whole previous build groups.
Some notes:
- This is implemented so that headers aren't checked more than once, so there
might be some checking tasks that won't do anything because the headers are
checked on another task. Even so, those headers are added to the result of
scan() in order to provide a consistent output to the user.
- It is safe manipulating the shared variable dispatched_headers because the
scan() is called before the task is added to the execution queue.
- Although we force ap_library_check_headers.scan() to always be called,
that's OK, because we use the scanning result of the compilation task, which
returns a cached value if there's no need to rescan.
That way we avoid recompiling source files that don't depend on vehicles.
Change notes:
- UTILITY_SOURCE_EXTS: moved to ap_library
- Task generators indexes: ap_library handles that now and in a better way
- Use of AP_STLIB_FEATURES: it doesn't make sense anymore, since the stlib
taskgen has empty source list
- Flags and defines: passed down to ap_library through AP_LIBRARIES_OBJECTS_KW
- Set use='mavlink' in AP_LIBRARIES_OBJECTS_KW instead of calls to
bld.ap_stlib().
That's a tool for creating task generators for libraries object files. One of
the key objectives of this patch is to provide a way to avoid recompiling
sources that are independent of vehicles.
This fix a bug introduced by 06a5156 ("waf: px4: reconfigure PX4Firmware for
each program"), with the removal of the call fw_task.set_run_after(cp_lib).
This allows the Vagrant VM to build PX4 using waf.
The initvagrant script has been changed to run as much as possible
as the Vagrant user.
jsbsim is now compiled by the vagrant user, and run from the source directory.
Try to make the various param files to follow similar namings:
- Lowercase the few ones using uppercase
- Use dash to separate name components
- Start with "copter", "plane", "rover", etc instead of the mix we
had
- Remove "params" from the filename since it's redundant with the
extension
Provide a function to register a post build routine to do the warnings. Do that
way so that the user can chose when to add the callback to the build (i.e.
allow the user to assert a desired order for the post build callbacks to be
called).
This allows to completely disable the tests. Even the gtest submodule is
not checked out allowing integration on build servers without needing to
download one more submodule.
This is different from the --notests flag. The latter only disables
executing the tests, but always use the submodule.
this converts existing pkg-config checks to use check_package, which
sets up all the needed variables after a check.
This also disables libdl and libiio for static builds, where they make
no sense
Some things worth mentioning:
- That version contains commits we had cherry picked on our submodule.
- There's a patch on top with a fix for the new process spawning used on
version 1.9.0. That has already been applied to upstream's master, but not
released yet.
- This patch also does necessary changes on our build system in order to
accommodate the upgrade. Basically:
- Use full task class names when calling create_task().
- Use always_run class attribute instead of the decorator, which is
deprecated.
Setting the "help" keyword argument may not fit in one line sometimes. This
patch adds the following convention to calls to add_option() in order to
address that issue in a better way:
1) The "help" keyword must always be the last argument to be passed.
2) If the help string is a literal string or a literal string with some
operation (e.g. "%" operator) and setting the "help" keyword in the code
doesn't fit a line (considering the limit of characters in a line), then
the help string must be a triple-quoted string. That has the advantage of
not having to have several "+" operations for long help strings. In that
case, the help message must start on the next line and the closing
triple-quotes must be on a separate line together with the closing
parenthesis.
The requirement (1) makes it easier to make the style exception in (2)
acceptable.
There's an upcoming patch that moves all static libraries to
`build/<board>/lib/`. That way, the program directory won't be created
automatically by the build system and that will cause problems for PX4 builds,
since it builds ardupilot programs as static libraries and copies stuff to the
program directory.
A (possible) bug in CMake makes it not to relink firmware_nuttx sometimes when
the following sequence of events happen with very short period of time in
between them:
1) cmake target build_firmware_px4fmu-v2 just finishes
2) px4-extra-files/libap_program.a is replaced with the next library
3) cmake target build_firmware_px4fmu-v2 is run
It's unfortunate to have to reconfigure PX4Firmware with a different path
because of the overhead added.
That problem was found with CMake 3.5.2 and is reproducible with the following
bash script (with git HEAD at ae3cb05 'HAL_PX4: disable "Overtime in task"
msg'):
```
modules/waf/waf-light configure --board px4-v2
modules/waf/waf-light build --targets bin/arduplane,bin/arducopter-quad
fails=0
total=0
while true; do
cp build/px4-v2/bin/libarducopter-quad.a \
build/px4-v2/px4-extra-files/libap_program.a
cmake --build build/px4-v2/modules/PX4Firmware \
--target build_firmware_px4fmu-v2 &> /dev/null
h1=$(sha256sum build/px4-v2/modules/PX4Firmware/src/firmware/nuttx/firmware_nuttx \
| cut -d" " -f1)
cp build/px4-v2/bin/libarduplane.a build/px4-v2/px4-extra-files/libap_program.a
cmake --build build/px4-v2/modules/PX4Firmware \
--target build_firmware_px4fmu-v2 &> /dev/null
h2=$(sha256sum build/px4-v2/modules/PX4Firmware/src/firmware/nuttx/firmware_nuttx \
| cut -d" " -f1)
[[ $h1 == $h2 ]] && ((fails++))
((total++))
printf "\r%d/%d" $fails $total
done
```
Create a new configuration task a configuration in the CMakeConfig object
changes. That allows building targets for different configurations in one waf
build run.
Update ccache to 3.2.5
Set ccache size
Display ccache statistics for each build
Disable ccache for configure phase
Export ccache bin path
travis: remove ccache stats before saving cache
Commit 8774f15 causes fly.CopterAVC test failure.
Here is the failure info below:
>>>> FAILED STEP: fly.CopterAVC at Tue May 17 13:21:56 2016 (fly_CopterAVC() got an unexpected keyword argument 'valgrind')
Traceback (most recent call last):
File "./Tools/autotest/autotest.py", line 406, in run_tests
if not run_step(step):
File "./Tools/autotest/autotest.py", line 232, in run_step
return arducopter.fly_CopterAVC(viewerip=opts.viewerip, map=opts.map, valgrind=opts.valgrind)
TypeError: fly_CopterAVC() got an unexpected keyword argument 'valgrind'
('check step: ', 'fly.CopterAVC')
FAILED 1 tests: ['fly.CopterAVC']
Here is the commit info below:
commit 8774f15b9a
Author: Peter Barker <pbarker@barker.dropbear.id.au>
Date: Mon Apr 11 18:05:39 2016 +1000
Tools: add valgrind option to autotest.py
:040000 040000 a111bc5b18609503f3b1 M Tools
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.
Before:
Checking for code snippet : yes
Checking for code snippet : yes
Checking for code snippet : yes
Checking for code snippet : yes
Checking for code snippet : no
Checking for code snippet : no
After:
Checking for HAVE_CMATH_ISFINITE : yes
Checking for HAVE_CMATH_ISINF : yes
Checking for HAVE_CMATH_ISNAN : yes
Checking for NEED_CMATH_ISFINITE_STD_NAMESPACE : yes
Checking for NEED_CMATH_ISINF_STD_NAMESPACE : no
Checking for NEED_CMATH_ISNAN_STD_NAMESPACE : no
The usual name for this header is config.h, but that's already used by
vehicles. Using uppercase could give the impression this is a
file to be modified, but it's not. Use lowercase instead.
Files that are not really part of the ROMFS in the folder might cause problems.
One problem that motivated this patch was caused because the make-based build
system copies the bootloader to the ROMFS in the source tree (mk/PX4/ROMFS)
instead of the build tree. That potentially could cause race condition between
the tasks created by 'px4_romfs_static_files' and 'px4_romfs_bootloader'.
Also, now we have only one task generator for static files.
That way we don't force other programs to be built on a directory of their
program group name. The directory name defaults to the program group.
We are separating those two concepts because of the upcoming support for
multiple groups for a program.
The find_realexec_path function was used for finding the toolchain path mostly
because of two reasons:
1) We couldn't really use CXX or CC variables because the user could set those
from the OS's environment and Waf wouldn't look for the executable file in
that case.
2) Our CI configuration sets up symlinks for ccache and find_realexec_path
works around that issue.
The bad side about using find_realexec_path() is that, besides working aroung
symlinks, it does the same thing that is done by Waf. This patch removes the
dependency for such a function by addressing each of the reasons above stated:
1) We create a local copy of os.environ and, if there's a variable with the
same name we are using, we remove it from the local copy.
2) As done before, we are looking for the cross ar program instead of gcc
program, since that is not used for ccache symlinks.
This is a better approach than checking command line options
--check-cxx-compiler and --check-c-compiler. Those values expect a list of
compilers to try instead of the compiler to use.
The benefits of this approach are:
- Allowing correct use of options --check-cxx-compiler and --check-c-compiler.
- Allowing user to pass CXX and CC environment variables, which is a common
way of selecting the compiler.
- Configuration is done *and committed* only for the specific compiler.
This is a better approach than checking command line options
--check-cxx-compiler and --check-c-compiler. Those values expect a list of
compilers to try instead of the compiler to use.
The benefits of this approach are:
- Allowing correct use of options --check-cxx-compiler and --check-c-compiler.
- Allowing user to pass CXX and CC environment variables, which is a common
way of selecting the compiler.
- Configuration is done *and committed* only for the specific compiler.
It makes more sense the toolchain Waf tool to be responsible of loading the
compilers. Furthermore, that allows toolchain tool to have control on doing
configuration before and after loading compiler tools.