On Thu, Apr 21, 2016 at 6:08 AM, Sassan Panahinejad <sas...@sassan.me.uk> wrote: > Hi, > > On several Yocto-based projects I've worked on, I've ended up accidentally > triggering rebuilds of large packages such as QT or Chromium. > > The example I keep running into at the moment is whenever I modify the > kernel config, I trigger Chromium to rebuild next time I rebuild the image. > This means losing as much as 4 hours every time. > > When searching for a solution, I found other posts and the workaround > usually given is not to rebuild the image after kernel changes and copy the > kernel manually. That's all very well, but I'm also making changes to other > parts of the system and therefore need to be able to rebuild the image > without waiting for Chromium to compile. > > The problem seems to come down to one of Chromium's deps depending on the > kernel for some headers. Now naturally changes to a dependency results in a > rebuild, but I the operator know that the change in question will not have > any affect.
Then use locked sstate mechanism. > > I'd like to just be able to blacklist rebuilding of Chromium and QT, but I > can't find a way other than sticking in some fake rules in the Chromium > recipe. In buildroot, one could often cheat by touching the relevant stamp > file to make it think it had rebuilt. Is the same possible in Yocto? > > Note: sstate-cache is enabled. > > Thanks > Sassan Panahinejad > > > -- > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
