This is the only driver doing this, using the system_initializing() from
scheduler to log selectively. Remove the check together with removal of
unused wrapper methods to semaphore.
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 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.
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.
Due to the way the headers are organized changing a single change in
an AP_Notify driver would trigger a rebuild for most of the files in
the project. Time could be saved by using ccache (since most of the
things didn't change) but we can do better, i.e. re-organize the headers
so we don't have to re-build everything.
Due to the way the headers are organized changing a single change in an
inertial sensor driver would trigger a rebuild for most of the files in
the project. Time could be saved by using ccache (since most of the
things didn't change) but we can do better, i.e. re-organize the headers
so we don't have to re-build everything.
With this patch only AP_InertialSensor/AP_InertialSensor.h is exposed to
most users. There are some corner cases to integrate with some example
code, but most of the places now depend only on this header and this
header doesn't depend on the specific backends.
Now changing a single header, e.g. AP_InertialSensor_L3G4200D.h triggers
a rebuild only of these files:
$ waf copter
'copter' finished successfully (0.000s)
Waf: Entering directory `/home/lucas/p/dronecode/ardupilot/build/minlure'
[ 80/370] Compiling libraries/AP_InertialSensor/AP_InertialSensor.cpp
[ 84/370] Compiling libraries/AP_InertialSensor/AP_InertialSensor_L3G4200D.cpp
[310/370] Linking build/minlure/ArduCopter/libArduCopter_libs.a
[370/370] Linking build/minlure/bin/arducopter
Waf: Leaving directory `/home/lucas/p/dronecode/ardupilot/build/minlure'
This is not used by any board and has a lot of commented out code. For
example, the compass is not enabled. The comment in the beginning of
the driver says it should serve as an example, but we should rather use
a working driver as an example. If this was at least a bit simpler and
that worked in the past we could refactor it to the new I2CDevice API.
This is not the case.
A string name allows to more easily expand the table: the board is
responsible for the name and doesn't have to declare it as a enum or
define. It's also easier to add 2 sensors of the same type.