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
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
