<div dir="ltr">Hi Patrick,<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 6, 2017 at 1:55 AM, Patrick Ohly <span dir="ltr"><<a href="mailto:patrick.ohly@intel.com" target="_blank">patrick.ohly@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">rm_work.bbclass never deletes downloaded files, even if they are not<br>
going to be needed again during the<br>
build. rm_work_and_downloads.bbclass is more aggressive in minimizing<br>
the used disk space during a build, but has other disadvantages:<br>
- sources required by different recipes need to be fetched once per<br>
recipe, not once per build<br>
- incremental builds do not work reliably because sources get<br>
removed without ensuring that sources gets fetched again<br>
<br>
That makes rm_work_and_downloads.bbclass useful for one-time builds in<br>
a constrained environment (like a CI system), but not for general use.<br>
<br></blockquote><div><br></div><div>I'd rather see this be a new class independent from rm_work. People can always in inherit both rm_work and rm_download.</div><div><br></div><div>That being said, since this doesn't operate at the fetch level, i.e. only remove things that were fetched as part of the current invocation of bitbake, I don't see why the user couldn't just "rm -rf downloads" themselves as part of the ci teardown.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Signed-off-by: Patrick Ohly <<a href="mailto:patrick.ohly@intel.com">patrick.ohly@intel.com</a>><br>
---<br>
meta/classes/rm_work_and_<wbr>downloads.bbclass | 33 ++++++++++++++++++++++++++++++<br>
1 file changed, 33 insertions(+)<br>
create mode 100644 meta/classes/rm_work_and_<wbr>downloads.bbclass<br>
<br>
diff --git a/meta/classes/rm_work_and_<wbr>downloads.bbclass b/meta/classes/rm_work_and_<wbr>downloads.bbclass<br>
new file mode 100644<br>
index 0000000..7c00bea<br>
--- /dev/null<br>
+++ b/meta/classes/rm_work_and_<wbr>downloads.bbclass<br>
@@ -0,0 +1,33 @@<br>
+# Author: Patrick Ohly <<a href="mailto:patrick.ohly@intel.com">patrick.ohly@intel.com</a>><br>
+# Copyright: Copyright (C) 2015 Intel Corporation<br>
+#<br>
+# This file is licensed under the MIT license, see COPYING.MIT in<br>
+# this source distribution for the terms.<br>
+<br>
+# This class is used like rm_work:<br>
+# INHERIT += "rm_work_and_downloads"<br>
+#<br>
+# In addition to removing local build directories of a recipe, it also<br>
+# removes the downloaded source. This is achieved by making the DL_DIR<br>
+# recipe-specific. While reducing disk usage, it increases network usage (for<br>
+# example, compiling the same source for target and host implies downloading<br>
+# the source twice).<br>
+#<br>
+# Because the "do_fetch" task does not get re-run after removing the downloaded<br>
+# sources, this class is also not suitable for incremental builds.<br>
+#<br>
+# Where it works well is in well-connected build environments with limited<br>
+# disk space (like TravisCI).<br>
+<br>
+inherit rm_work<br>
+<br>
+# This would ensure that the existing do_rm_work() removes the downloads,<br>
+# but does not work because some recipes have a circular dependency between<br>
+# WORKDIR and DL_DIR (via ${SRCPV}?).<br>
+# DL_DIR = "${WORKDIR}/downloads"<br>
+<br>
+# Instead go up one level and remove ourself.<br>
+DL_DIR = "${BASE_WORKDIR}/${MULTIMACH_<wbr>TARGET_SYS}/${PN}/downloads"<br>
+do_rm_work_append () {<br>
+ rm -rf ${DL_DIR}<br>
+}<br>
<span class="HOEnZb"><font color="#888888">--<br>
2.1.4<br>
<br>
--<br>
______________________________<wbr>_________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org">Openembedded-core@lists.<wbr>openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/<wbr>mailman/listinfo/openembedded-<wbr>core</a><br>
</font></span></blockquote></div><br></div></div>