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.
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.
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
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.
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.
In the upcoming build for PX4 boards, we will pass down the program a single
static library to PX4 Firmware's cmake build system. This patch is partially
providing a way to do that: the configuration for PX4 will define the
AP_PROGRAM_AS_STLIB environment variable.
The function ap_program() was the only one that was using it, so let's just
inline it. Besides, the name was misleading, since the (only) feature added was
for programs instead of general task generators.
That will make platform specific naming be ignored. We use a string instead, to
let Waf tweak the target name correctly for us. The '#' prefix is to tell Waf
that the path is relative to bld.bldnode (instead of bld.path, which is the
default).
That allows options being declared where they're really used. Additionally, we
load ardupilotwaf after the other tools so that we can create our groups after
all non-ardupilot option groups are created. That makes our groups appear as
the last ones in the help message, which makes it easier to locate them.
The gtest header uses lots of undefined macros, showing lots of warnings
if we enable -Wundef. Ideally we could use a #pragma to ignore the
warning only from the correct header, but this currently doesn't work
with g++ - see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431
So for now we disable the warning completely when compiling gtest or any
test that uses its header.
Thanks Gustavo Sousa
That is a workaround so that one can use `waf bin tests`, for example. In our
context, the only restriction to the task generators creation is values defined
during configuration. Thus, ideally, the recursion and task generators creation
should be done only once for multiple build calls. We should do that in the
future.
Rationale:
1. That function creates a separate build context class instead of just
creating a wrapper for calling build (previous approach).
2. The check command isn't a build shortcut since there's no way of calling it
without using 'check' explicitly.
The following fixes where applied:
- Value for APM_BUILD_DIRECTORY must be prefixed with APM_BUILD_
- Renamed parameter name to sketchname, so we differentiate the real program
name from the legacy sketch name
- Use directory name instead of program name as argument for
_get_legacy_defines()
Bind functions used in wscripts to build context. Additionally, a new function
is created and also decorated with @conf, common_vehicle_libraries(), which
returns COMMON_VEHICLE_DEPENDENT_LIBRARIES. This patch is a preparation for
making wscripts use methods bound to the build context instead of using them
directly from ardupilotwaf.
The destination directory for binaries should be
<build_dir>/<board>/bin/ and not
<build_dir>/<board>/<where-wscript-file-is>/bin
The same reasoning can be applied for others: tools, examples, etc
should follow the same rule.
Before this patch, compiling for example ArduPlane for navio we would
have:
[339/339] Linking build/navio/ArduPlane/bin/ArduPlane
And now we have:
[339/339] Linking build/navio/bin/ArduPlane
Use platform-neutral way in python to join path components to improve
readability. Both will work when passing down to waf's Node object, even
on Windows.
waf's terminology might be a bit confusing regarding the word 'target'. As an
attribute for a task generator, it means the paths of the files supposed to be
built. As a command line option (--target), it means the list of names of the
task generators to be used in the build.
Before this commit, only vehicles programs had their task generators' target
parameter value different from the name parameter. Now, there's no distinction
between those two parameters for the case of programs.
That enable the easy creation of custom build commands with the purpose of
creating "shortcuts" for execution from command line.
For example, consider the following code fragment from a wscript:
```
copter = ardupilotwaf.build_shortcut(targets='ArduCopter')
```
With that, one can just issue `waf copter` instead of
`waf --target ArduCopter`.
The parameter target is made optional because more parameters might be added to
this function in the future.
Benchmarks now go to `build/<board>/benchmarks/` and tests to
`build/<board>/tests/`. That's done by using ardupilotwaf.program() and passing
blddestdir and program_name.
The only exception is for binaries that go in 'bin', like vehicles.
That way, partial builds follow the rule:
- If building a vehicle or some helper that goes into 'bin', just use the
binary name as the argument for --target. Example: `waf --target
ArduCopter`.
- For other binaries, the name of the directory they are placed in must be
used. Example: `waf --target tests/test_vectors`.
That param defines where the binary will be saved in the build directory,
namely `build/<board>/<blddestdir>`. The default is 'bin', for binaries that are
to be shipped for installation.
Gustavo Jose de Sousa
Andrew Tridgell
Lucas De Marchi
Ricardo de Almeida Gonzaga
Daniel Frenzel