[yocto] confusion about DEPENDS vs RDEPENDS

[lothar at denx.de]

Hello Paul,

I followed this very interesting thread, and have a question on the last 
statement, just for understanding:

Are the limitations you are explaining here, the same as mentioned in...
http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html
...under "Checksums (Signatures)", telling that:
"Consider a case with in-line Python, for example, where BitBake is not 
able to figure out dependencies."   ? So to speak, are those limitations 
the cases, where bitbake is not able to figure out dependencies 
correctly?

Thanks in advance,
Lothar


> 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