[yocto] confusion about DEPENDS vs RDEPENDS

[Paul Eggleton]

Hi Paul / Nicolas,

On Wednesday 28 August 2013 15:15:27 Paul D. DeRocco wrote:
> From: Nicolas Dechesne
> > if the source code changes, the version of the recipe needs
> > to change too. if you change the source code without bumping
> > the version, the package might not be rebuilt properly
> > indeed. and that can explain the behavior you are seeing. if
> > 'someapp' does not change, it would be rebuilt only if one of
> > its dependencies was rebuilt.
> 
> If you're making lots of changes in the course of debugging, isn't it
> reasonable just to do a cleansstate on the recipe to force it to be
> rebuilt?

Current versions of the build system (denzil/1.2+, although refinements have 
been made since then) are task signature-based. That means as far as the build 
system is able to determine its inputs, if those change it should be able to 
rebuild all of the output to match. Known limitations:

* Upstream software that doesn't properly rebuild when reconfigured. In most 
cases this should be considered as a bug in the recipe. Separating S from B 
can help here as I mentioned earlier, and you can see in dylan/1.4+ in 
meta/conf/distro/include/seperatebuilddir.inc that we've been enabling 
separate recipe build dirs for a number of recipes to help with this.

* Editing the unpacked/patched source code in the recipe's work directory 
(i.e. tmp/work/...). Note that this is not something that is discouraged - in 
fact it can be a very useful development aid. However, you do need to be aware 
of the need to force the appropriate tasks to re-execute after you have made 
changes in there i.e. bitbake -c compile -f <recipe> or bitbake -C compile 
<recipe>, since the build system cannot detect these kinds of changes on its 
own.

* Items remaining in the sysroot when recipes are completely renamed (i.e. 
when PN changes) or when a recipe is removed. We saw this recently with the 
mesa-dri -> mesa rename. Currently there's no way for the system to know what 
replaces what when PN changes or what to do when a recipe completely vanishes, 
you just have to clean out the old recipe's files in the sysroot. This can of 
course happen if you add and remove layers without deleting TMPDIR, so care 
should be taken when doing that. This is an difficult issue to solve 
practically; there is discussion of this issue here for those interested: 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=4102

* If you use runtime packaging ("package-management" in IMAGE_FEATURES) and 
you're putting the packages into a feed and expect on-target upgrades to work 
consistently from those feeds without manually bumping PR in recipes on every 
material change, you need to enable the PR service as described in the 
development manual so that PR increments automatically.

* Changes on the host system affecting native recipes - less likely to cause 
issues, but worth being aware of. It can happen that adding or removing 
packages on the host system changes the configuration of native recipes without 
automatically triggering a rebuild - a good example is how we allow qemu-
native to build on systems with and without X11; if you added SDL and X11 to a 
system on which you'd already built qemu-native beforehand, in the absence of 
other changes you'd have to cleansstate or otherwise force a rebuild of qemu-
native to have a native QEMU that supported graphical output.


However, with the caveats above, most of the time you can rely upon the build 
system to determine what to do when things change. Of course, yes, if you want 
to just force a recipe to rebuild you have the option of bitbake -c 
cleansstate <recipe> before building it again, but most of the time that's 
going to be more than is needed.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre