On Fri, Jan 6, 2017 at 11:22 AM, Patrick Ohly <[email protected]> wrote:
> On Fri, 2017-01-06 at 10:31 -0800, Randy Witt wrote: > > > > > I'd rather see this be a new class independent from rm_work. People > > can always in inherit both rm_work and rm_download. > > I'm not sure whether it's worth supporting that mode: what would be the > motivation for removing downloads, but not the work directory? > > There are times that the work directories help with the debugging of build failures. The logs aren't always enough. So a person might want to do something like remove the downloads, but preserve the actual work, especially in the case of failures. I'll admit it is a fabricated scenario, but in general I'm against one knob requiring the turning of another knob. > The motivation for rm_work_and_downloads.bbclass is the same as for > rm_work.bbclass: reducing the required disk space *during* the build, to > get builds to succeed which otherwise would run out of disk space. > > Disk space isn't the only motivation for rm_work. It also allows for deletion of large amounts of inodes before they've been flushed to disk. So rather than taking minutes worth of time to clean up post build, and thrashing media that other tasks may be using, it is almost instantaneous because everything is still in the page cache. Also the build itself can be faster for the same reason, there is no waiting for data to be flushed out to disk( because it was deleted while still in the page cache) and thus impacting reads in other parts of the build. > A "rm -rf downloads" at the end of the build doesn't help achieve that > goal. > > That's true, I hadn't yet processed it completely. Ignore that comment. :) As an overall comment though, I really like the idea of rm_work not being deferred for so long. It always seemed strange to me to see the thundering herd of rm_works after certain do_builds would finish.
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
