Make it use rsync command. That's a workaround to allow user using --upload
option, which in fact appends the 'rsync' to the command chain. A bad
side-effect of this is that the build summary is output twice for a command
like 'waf copter --upload'.
Differentiating if the path should be relative to the build dir or the
ROMFS dir based purely on the type of the item is not a good approach.
This prepares the way to have more files on ROMFS with different names
on src and dst.
Yes, we know we are using them. Remove warnings like:
CMake Deprecation Warning at /usr/share/cmake/Modules/CMakeForceCompiler.cmake:93 (message):
The CMAKE_FORCE_CXX_COMPILER macro is deprecated. Instead just set
CMAKE_CXX_COMPILER and allow CMake to identify the compiler.
Call Stack (most recent call first):
cmake/toolchains/Toolchain-arm-none-eabi.cmake:37 (cmake_force_cxx_compiler)
/home/lucas/p/dronecode/ardupilot/build/px4-v2/modules/PX4Firmware/CMakeFiles/3.6.2/CMakeSystem.cmake:6 (include)
CMakeLists.txt:204 (project)
We currently are unable to build on MacOSX unless we give waf the
--check-cxx-compiler g++. Change the compiler order to search for
gcc/g++ first instead of clang/clang++.
When we are checking if a header is available we can't pass -I argument
to our missing/ directory. Otherwise we would end up telling the build
that a header is available when it actually isn't.
This fixes the build of sitl in MacOS with clang.
On Windows, using MSYS Makefiles generator doesn't work very well when the
CMakeLists.txt files use custom commands with paths as arguments. Furthermore,
MinGW Makefiles generator can't be used if sh.exe is in the system's path and
some build systems rely on sh for certain tasks (which is the case of PX4
Firmware build). Because of that, the list of generators for Windows has been
narrowed to Ninja and NMake Makefiles.
Here we do the following:
1) Move the pkg-config check to boards.py so we only check of it for
linux boards
2) Use cfg.find_toolchain_program() if possible, for example, for AR
That's more correct than setting Waf environment variables:
(1) We don't need to worry about differences between OSes - the previous
implementation was actually broken for Windows because the program names in
the environment variables were missing the ".exe" extension.
(2) That looks better than looping over possible compiler names and running
the configuration transactionally multiple times.
Implicit dependency scanning takes significant time and, since it doesn't
produce files, it's okay to keep the resulting information across clean
commands as long as the scanner is triggered again if there's need to. This
commit accomplishes that.
The advantage of this approach can be observed by the following timings when
building the group "bin":
Method Time
------------------------------------------------------------------------
Fully clean build 5m18.633s
Clean build with scanning result persisted 4m23.346s
Clean build with ccache but non-persistent scan results 1m40.125s
Clean build with scanning results persisted and with ccache 14.843s
While at it, move management of information persisted across clean commands to
a separate module.
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).
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.
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.
Andrew Tridgell
bugobliterator
Peter Barker
mirkix
Mark Whitehorn
HeBin
Staroselskii Georgii
Lucas De Marchi
José Roberto de Souza
Francisco Ferreira
davidaroyer
Miguel Arroyo
Kevin Lopez Alvarez
Gustavo Sousa
Pierre Kancir
Eugene Shamaev
Randy Mackay
Julien Beraud
floaledm
Martin Evans
Gustavo Jose de Sousa