That seems to work. Thanks a lot !
On 20 January 2014 17:36, Paul Eggleton <[email protected]>wrote: > On Monday 20 January 2014 17:28:18 Jacques Guillou wrote: > > On 20 January 2014 16:34, Paul Eggleton <[email protected]> > > 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://[email protected]/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 > _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
