[oe] Bitbake command to clean dependees ?

[Jacques Guillou]

That seems to work.
Thanks a lot !


On 20 January 2014 17:36, Paul Eggleton <paul.eggleton at linux.intel.com>wrote:

> On Monday 20 January 2014 17:28:18 Jacques Guillou wrote:
> > On 20 January 2014 16:34, Paul Eggleton <paul.eggleton at linux.intel.com>
> > wrote:
> > > On Monday 20 January 2014 15:57:39 Jacques Guillou wrote:
> > >> By default (at least with Yocto), it seems like forcing the rebuild
> of a
> > >> specific package (via "bitbake -c cleanall MyPackage") does not mark
> > >> dependees as "to be rebuilt", which is a problem for me. Is there a
> way
> > >> to change that behavior ? Maybe there is a specific command or
> parameters to
> > >> be passed to bitbake so that performing a "cleanall" on a given
> package
> > >> also performs a "cleanall" on all dependees ?
> > >
> > > OpenEmbedded uses signatures for each task (derived from the task's
> > > dependencies, both in terms of variable values and other tasks) to
> > > determine whether tasks need re-executing; so, for example if you
> changed
> > > SRC_URI in a recipe then the system knows that do_fetch depends upon
> the
> > > value of SRC_URI, so the signature of do_fetch changes and it will
> > > re-execute followed by items it depends upon such as do_unpack,
> do_patch
> > > etc. for the same recipe. Just forcing a recipe to rebuild by cleaning
> it
> > > with -c cleanall and then building it again doesn't change any of its
> > > task signatures, so BitBake will assume no dependees need rebuilding.
> > >
> > > The correct way to force a task and all of its dependencies to
> re-execute
> > > is to use bitbake -c <command> -f or bitbake -C <command>, where
> > > <command> is the task name without the do_ prefix. However, under most
> > > circumstances the build system is already capable of determining itself
> > > when tasks need re-executing, e.g. if you change a variable value or
> edit
> > > a local file mentioned in SRC_URI. The question is why do you want to
> do
> > > this forcing, i.e. what change(s) have you made that the build system
> > > otherwise would not be picking up?
> >
> > What I would like to do is to be able to trigger the build of a
> > complete image whenever a new commit has been pushed into a specific
> > GIT repository. I understand that the normal way to proceed is to
> > update the corresponding recipe so that it points to the new commit.
> > Since the recipe would have been updated, the packages which have a
> > dependency to the updated packages would be rebuilt as well, but I
> > would really prefer a solution where I don't have to update any
> > recipe. Please note that what I am trying to do would only be good for
> > internal testing. I understand that it is a much better practice to
> > use well defined commit-ID as soon as some kind of delivery, since it
> > is the only way to properly identify a version.
> >
> > I am currently testing using a recipe which contains the following lines:
> >
> > SRC_URI =
> > "git://git@git.mycompany.com/mycomponent.git;protocol=ssh;branch=master"
> > SRCREV = "master"
> > PV = "1.0${SRCREV}"
> >
> > Using that recipe, if I first clean the package with "bitbake -c
> > cleanall mypackage" and trigger a complete image build, bitbake always
> > retrieves the head of the master branch when the package is to be
> > fetched, and compiles the package, which is the result I expect.
> > Unfortunately, after that package is rebuilt, bitbake seems to
> > consider that the dependees of that package do not have to be rebuilt,
> > since no change has been done to any recipe.
> >
> > Is there any way to get this to work properly ? Maybe there is a way
> > to tell bitbake to dynamically generate the value of the "PV"
> > attribute based on the GIT commit-ID which is actually used ?
>
> Indeed there is:
>
> SRCREV = "${AUTOREV}"
> PV = "1.0+git${SRCPV}"
>
> You should also enable the PR service if you want the prefix numbers to
> increment properly such that the version is always greater when the git
> hash
> changes (allowing on-target upgrades to work):
>
>
> http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working-with-a-pr-service
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>