In several places we use functions like asprintf() that are only
available in libc when _GNU_SOURCE is defined. Always define _GNU_SOURCE
since we always want to use them.
This fixes the build on Windows using cygwin.
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.
Use program group name instead of task generator name. That way all programs
belonging to a product are built. That will be the case for different frames
for copter.
Without this patch, if nodes that don't yet exist in the filesystem in
bld.bldnode were created before calls to this function, they'll be removed from
the tree in memory because "*" is passed to ant_glob() and the "remove" keyword
argument defaults to True.
In the future, gbenchmark will be build using a cmake waf tool, which will
require cmake to be installed. We add this option so that users without cmake
can continue use the build system with no problems.
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.
Gustavo Jose de Sousa
Lucas De Marchi
Ricardo de Almeida Gonzaga
Siddharth Bharat Purohit