> -----Original Message----- > From: Dev [mailto:[email protected]] On Behalf Of Saul Wold > Sent: Wednesday, January 21, 2015 3:45 PM > To: [email protected] > Cc: [email protected]; 유덕인 > Subject: Re: [Dev] Yocto Tizen - clean, continue option > > On 01/20/2015 08:36 PM, 정대순 wrote: > > Hi, > > > > In before e-mail, My questions are separation. > > > > In firt question, I want to clean to target.(all packages) > > > > So, I input 'bitbake -c cleanall tizen-common-core-image-crosswalk-dev', and > run > > 'bitbake tizen-common-core-image-crosswalk-dev'. > > > > But, build started 5748 task. (msg : Currently 1 running tasks (5749 of > > 5752)), > > not first task. > > > > Is it right? In my opinion, just clean some of packages. > Not quite, the 3 clean tasks (clean, cleansstate, cleanall) are tasks > against recipes or targets, they don't affect the dependencies of the > target. So the above cleanall just cleans the specific target listed on > the command line. I have been struggling with this concept a bit myself. The standard clean option clears the workspace and sysroot (and any artifact that's in there), but what does that mean when the target is something different than a package (i.e. a complete image such as tizen-ivi-core)?
> > > > > (When I run the build after git clone, started '1 of 5752' task.) > > > > How to build started in init status? Delete a 'tmp-glibc' directory? > > > I would ask why do you need to start from the "initial" state, if you > change a recipe it will rebuild that target. Deleting the tmp-glibc is a > pretty big hammer. My own trick is to initialise a new different build dir by re-running the script... that's also a pretty big hammer :-) There are times when you don't know if or up to what point you can trust the cache... this is when I feel I need to go back to an initial state. > > > In second question, I just curious about build break. > > > > When build break occur, if I run 'bitbake tizen-common-core-image- > crosswalk-dev' > > again, does it continue break point? > > > It will continue, from the failure, but unless you fix the failure it > will fail again! This is exactly what I saw the other day. What confused me quite a bit (and made me go back to the initial state) is that when I enabled more debug output (-D), it proceeded to building more packages after the rpm-native failure, something it had never done before. Maybe this is the normal behaviour but it's not very intuitive to the Yocto newbie that I am (and yes, I still have to read most of the documentation on Yocto). Geoffroy ----------------------------------------------- Intel Corporation NV/SA Kings Square, Veldkant 31 2550 Kontich RPM (Bruxelles) 0415.497.718. Citibank, Brussels, account 570/1031255/09 _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
