[oe] script to remove orphaned files

Frans Meulenbroeks fransmeulenbroeks at gmail.com
Tue Aug 24 06:32:03 UTC 2010


2010/8/23 Khem Raj <raj.khem at gmail.com>:
> On Mon, Aug 23, 2010 at 1:19 PM, Frans Meulenbroeks

>
> Sometimes I run into a issue and then I look into the existing patches
> and apply it or port it forward/backward
> that solves it. This will be not easily possible once these patches
> are removed. but thats not such a big issue I do
> not have a strong opinion on this either way.
>

I've been thinking about that as well. Onthe other hand some of these
files seem to be relics of the past that apply to older versions and
are not relevant at all.
Anyway, if there is a maintainer who feels some files are useful, we
can just keep them afaik. Just want to get rid of the orphaned stuff.

BTW; there is one change needed for the script. Right after turning
off my computer last evening I realised that some patches use ${PV}.
Just did a quick check: there are 78 or so of them (and most are
expanded only once). The script fails for these.

Solution is to add the following line before the find:
grep -q "file://.*\\$" *.bb *.inc && echo "cannot handle recipes with
metavariables in the name" && exit

Actually it would probably be nicer to have a parser that could parse
the recipes and based upon SRC_URI could decide on what is needed and
not.
(and maybe also reorder things, detect for things that are syntaxwise
ok, but that are an indication of an error (e.g. a double assignment
of a variable).
It could also tell about unused variables etc.

Currently the parser is in bitbake, I have no idea on how to hook
those kind of checks in the parser, or how to craft a python parser
that would be able to do the above.
It would be nice if someone with more python knowledge could give that a stab.
BTW: I have been thinking about crafting a parser with lex/yacc, but
especially the override mechanism does not allow to make a simple .y
file for it (e.g. SRC_URI cannot be made a token because we also can
have SRC_URI_xyz etc)

Frans




More information about the Openembedded-devel mailing list