On Thu, Nov 15, 2012 at 9:19 AM, Martin Jansa <[email protected]>wrote:
> On Thu, Nov 15, 2012 at 08:25:20AM -0700, Chris Larson wrote: > > On Thu, Nov 15, 2012 at 12:30 AM, Martin Jansa <[email protected] > >wrote: > > > > > * it's not very universal, but works with default oe-core setup and > > > shows basic HOW-TO. It can be improved later. > > > > > > Signed-off-by: Martin Jansa <[email protected]> > > > --- > > > V2: added .pyo to WHITELIST > > > shorter filenames > > > TMPDIR > > > added duplicates but not shown > > > > > > V3: use also populate-sysroot.MACHINE, manifest name for > populate-sysroot > > > was changed in febeaf3d1b8917b660c7279b008d8b03337568e9 > > > > > > V4: dropped eglibc-initial work around, it was fixed in oe-core > > > > > > scripts/sstate-sysroot-cruft.sh | 34 > ++++++++++++++++++++++++++++++++++ > > > 1 file changed, 34 insertions(+) > > > create mode 100755 scripts/sstate-sysroot-cruft.sh > > > > > > diff --git a/scripts/sstate-sysroot-cruft.sh > > > b/scripts/sstate-sysroot-cruft.sh > > > new file mode 100755 > > > index 0000000..ca23dcf > > > --- /dev/null > > > +++ b/scripts/sstate-sysroot-cruft.sh > > > @@ -0,0 +1,34 @@ > > > +#!/bin/sh > > > + > > > +# Used to find files installed in sysroot which are not tracked by > sstate > > > manifest > > > +# Update BASE > > > + > > > +BASE="/OE/oe-core" > > > > > > > This seems interesting, but I have a few comments/concerns. > > > > 1) don't hardcode BASE, figure out the path relative to the script's > > location, e.g. BASE="$(cd $(dirname $(dirname $0)) && pwd)" > > 2) output files shouldn't go into oe-core directly, as oe-core isn't > > guaranteed to be writable, and it's more common to expect output from a > > script like this to go relative to the current directory, or a temp > > directory > > 3) extract TMPDIR from bitbake -e, rather than hardcoding that, as that > > breaks for any distros or users which separate their tmpdirs by distro, > or > > set TCLIBCAPPEND = "" > > Ah in this case BASE is not directory with oe-core layer but one above. > Still trivial to determine relative to the script's location. Adding an extra call to dirname, or an extra '/..' isn't particularly tough. I didn't want to use bitbake -e, so that this script can be executed > when some other bitbake process is running. > 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. As said it's not really universal (I wrote it just to confirm something > and then shared it to find if someone else finds it also usefull to > improve it). > 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' ;) -- Christopher Larson
_______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
