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.
That is useful when the user wants to build with one or more submodules at a
specific revision. In case of a developer, that is useful for when a submodule
is in modification process and she needs to (constantly) test the build.
With this change, there's no need to verify if the submodule is initialized,
because the submodules in GIT_SUBMODULES are automatically initialized and
updated if necessary before the build tasks are performed.
One downside of this change is that Google Benchmark configuration is now done
only during build. However that is minor, since now there are easy ways to
separately build different targets and program groups, so that a fail in
benchmark build doesn't really affect the other targets.
We define three build groups and set post_mode as POST_LAZY, which makes one
group be posted only after the previous one. That enables us to correctly
define dynamic sources with submodules and generators that may or may not
depend on submodules (e.g. mavgen - this one depends on mavlink submodule).
The groups are defined below, in that order:
1. git_submodules: contains taskgens that initialize and update submodules.
2. dynamic_sources: contains taskgens that generate sources used by the build.
3. build: contains the normal taskgens.
That makes the code cleaner and better readable. Futhermore, it's easier to add
a pattern for recursion.
Additionally, this commit remove Tools from the exclusion list as that is not
necessary.
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.
Now that the concept of programs group is used and 'bin' is the default program
group, the command check needed to be adapted so that (i) it is consistent with
the other build command and (ii) it defines 'all' as its target programs group.
That will make it possible to replace calls of the form
`ardupilotwaf.<method>(bld, <keyword-args...>)` with
`bld.<method>(<keyword-args...>)` in the wscripts.
Advantages of that approach:
- there is no need to import ardupilotwaf in every single wscript
- it follows the same standard used by c and cxx tools (like bld.program,
bld.stlib etc)
- semantically, ap_program, ap_stlib, example etc are all build related
methods, so it makes sense to bind them to the build context
- from the wscripts' perspective, the code is cleaner, since ardupilotwaf,
which is not specific to just build contexts, isn't *explictly* used
That makes it possible to build tests on distributions that don't provide
official packages for gtest. For example, the travis environment is Ubuntu,
which doesn't have official package for gtest library.
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.
The option target for the waf task generator is meant for actual files that are
going to be build. Since our target files are dynamic, let's change the code to
use a new parameter output_dir instead.
The task generator for the mavlink headers is given a name 'mavlink' and is
added as a dependency to all local static libraries, because all of them use
sources that include mavlink headers. It would be nice to have a good way to
detect sources that use mavlink headers or to declare list of libraries that
use the headers, so that the dependency could be added automatically.
Additionally, there's a minor change in syntax for the task generator: using
strings directly instead of lists.
Several boards require cross compilation. The objective of this change is to
allow to specify the target architecture in the board definition, so that the
correct toolchain is selected. The cross compilation mechanism will be
implemented in the next commits.
The TODOs removed with this patch were already fixed. Below is the explanation
for each.
- TODO: add support for unit tests.
- Supported already added.
- TODO: Check if we should simply use the signed 'waf' "binary" (after
verifying it) instead of generating it ourselves from the sources.
- We're using a submodule for waf.
- TODO: evaluate if we need shortcut commands for the common targets
(vehicles). currently using waf --targets=NAME the target name must contain
the board extension so make it less convenient, maybe hook to support
automatic filling this extension?
- There's no need of adding the extension anymore.
- TODO: Once HAL patches get in, need to filter out the HAL based on the
bld.env.BOARD.
- The board-specific HAL library folders is indicated in
bld.env.AP_LIBRARIES.
Instead of a dictionary of dictionaries, have a dictionary of
ConfigSets. Using ConfigSet have two benefits: (1) allow easily copying
values from other, (2) have syntax for specifying the keys directly as
attributes.
With this change now it's easier to specify minlure without
repetition. New boards can override a value, append or prepend depending
on the need.
DEFINES attribute is treated as a dictionary instead of a list, so
that's easier to override values (at expense of ordering). When reading
the board environment, the code converts back to a list.
The board configuration is now stored in a separate file, there's also a
function to get the boards names.
The command will be used to allow travis script to know which boards are
already supported by the waf build system. This is useful while the transition
to the new build system is on going. The command can be removed when the
transition is done and it's not used anywhere besides travis script.
It was implemented in such a way that gtest is required only if the user wants
to build and run tests. Initially we're considering all tests should be gtests.
We can change that assumption in the future if necessary.
We're currently using the tests standard error for reporting tests. We can add
TAP later to integrate with other tools.
Additionally, this patch simplifies the exclude patterns passed to
collect_dirs_to_recurse.
Gustavo Jose de Sousa
Lucas De Marchi
Siddharth Bharat Purohit
Caio Marcelo de Oliveira Filho