<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 15, 2012 at 9:19 AM, Martin Jansa <span dir="ltr"><<a href="mailto:martin.jansa@gmail.com" target="_blank">martin.jansa@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb adM"><div class="h5">On Thu, Nov 15, 2012 at 08:25:20AM -0700, Chris Larson wrote:<br>
> On Thu, Nov 15, 2012 at 12:30 AM, Martin Jansa <<a href="mailto:martin.jansa@gmail.com">martin.jansa@gmail.com</a>>wrote:<br>
><br>
> > * it's not very universal, but works with default oe-core setup and<br>
> > shows basic HOW-TO. It can be improved later.<br>
> ><br>
> > Signed-off-by: Martin Jansa <<a href="mailto:Martin.Jansa@gmail.com">Martin.Jansa@gmail.com</a>><br>
> > ---<br>
> > V2: added .pyo to WHITELIST<br>
> > shorter filenames<br>
> > TMPDIR<br>
> > added duplicates but not shown<br>
> ><br>
> > V3: use also populate-sysroot.MACHINE, manifest name for populate-sysroot<br>
> > was changed in febeaf3d1b8917b660c7279b008d8b03337568e9<br>
> ><br>
> > V4: dropped eglibc-initial work around, it was fixed in oe-core<br>
> ><br>
> > scripts/sstate-sysroot-cruft.sh | 34 ++++++++++++++++++++++++++++++++++<br>
> > 1 file changed, 34 insertions(+)<br>
> > create mode 100755 scripts/sstate-sysroot-cruft.sh<br>
> ><br>
> > diff --git a/scripts/sstate-sysroot-cruft.sh<br>
> > b/scripts/sstate-sysroot-cruft.sh<br>
> > new file mode 100755<br>
> > index 0000000..ca23dcf<br>
> > --- /dev/null<br>
> > +++ b/scripts/sstate-sysroot-cruft.sh<br>
> > @@ -0,0 +1,34 @@<br>
> > +#!/bin/sh<br>
> > +<br>
> > +# Used to find files installed in sysroot which are not tracked by sstate<br>
> > manifest<br>
> > +# Update BASE<br>
> > +<br>
> > +BASE="/OE/oe-core"<br>
> ><br>
><br>
> This seems interesting, but I have a few comments/concerns.<br>
><br>
> 1) don't hardcode BASE, figure out the path relative to the script's<br>
> location, e.g. BASE="$(cd $(dirname $(dirname $0)) && pwd)"<br>
> 2) output files shouldn't go into oe-core directly, as oe-core isn't<br>
> guaranteed to be writable, and it's more common to expect output from a<br>
> script like this to go relative to the current directory, or a temp<br>
> directory<br>
> 3) extract TMPDIR from bitbake -e, rather than hardcoding that, as that<br>
> breaks for any distros or users which separate their tmpdirs by distro, or<br>
> set TCLIBCAPPEND = ""<br>
<br>
</div></div>Ah in this case BASE is not directory with oe-core layer but one above.<br></blockquote><div><br></div><div>Still trivial to determine relative to the script's location. Adding an extra call to dirname, or an extra '/..' isn't particularly tough.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I didn't want to use bitbake -e, so that this script can be executed<br>
when some other bitbake process is running.<br></blockquote><div><br></div><div>I don't see having to hardcode assumptions about the environment as a net win, personally. At least make them arguments, or add an argument to optionally use bitbake -e, or let it take vars from the environment.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As said it's not really universal (I wrote it just to confirm something<br>
and then shared it to find if someone else finds it also usefull to<br>
improve it).<br></blockquote><div><br></div><div>If it can't be used in a wide variety of circumstances, I'd argue against its inclusion in oe-core until such time that it's ready. The subject of this thread didn't include "RFC' ;)</div>
</div>-- <br>Christopher Larson<br>
</div>