On Mon, Jan 9, 2017 at 2:25 AM, Patrick Ohly wrote:
>
> >
> > In principle I agree. Okay, let's separate the two.
>
> I hit one snag when starting to do that: the implementation of download
> removal depends on do_rm_work from rm_work.bbclass for hooking into the
> build
On Sat, 2017-01-07 at 09:09 +0100, Patrick Ohly wrote:
> On Fri, 2017-01-06 at 13:29 -0800, Randy Witt wrote:
>
>
> > 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
On Fri, 2017-01-06 at 13:29 -0800, Randy Witt wrote:
> 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
On Fri, Jan 6, 2017 at 11:22 AM, Patrick Ohly
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
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
Hi Patrick,
On Fri, Jan 6, 2017 at 1:55 AM, Patrick Ohly wrote:
> rm_work.bbclass never deletes downloaded files, even if they are not
> going to be needed again during the
> build. rm_work_and_downloads.bbclass is more aggressive in minimizing
> the used disk space
rm_work.bbclass never deletes downloaded files, even if they are not
going to be needed again during the
build. rm_work_and_downloads.bbclass is more aggressive in minimizing
the used disk space during a build, but has other disadvantages:
- sources required by different recipes need to be fetched