<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 11, 2014 at 12:10 PM, Burton, Ross <span dir="ltr"><<a href="mailto:ross.burton@intel.com" target="_blank">ross.burton@intel.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":e6" class="a3s" style="overflow:hidden">So yet again I was wrestling PACKAGES and FILES in an attempt to get<br>
everything in the right place, the latest complication being ptest and<br>
where they are in the PACKAGES chain making correct splitting tricky.<br>
<br>
Again I wondered why debug packages need explicit FILES, and did a<br>
quick hack as a proof of concept to put split debug objects and source<br>
code into PN-dbg automatically, instead of through explicit FILES.<br>
This hack is at best: it clears FILES_PN-dbg in bitbake.conf and as it<br>
executes do_package FILES is set for each file it handles. As PN-dbg<br>
is at the beginning of PACKAGES it takes the right files before other<br>
packages, apart from when other =+ is used as in ptest... so my<br>
original reason for looking at this is still a problem. This is in<br>
ross/debug in poky-contrib, fwiw.<br>
<br>
Before I look at this again and avoid FILES entirely, I should check<br>
that my assumptions are valid in the greater community. My big<br>
assumptions here are that 1) every recipe has a single -dbg package,<br>
2) every debug object belongs in that -dbg package, 3) only debug<br>
objects and sources belong in that -dbg package.<br>
<br>
I know there are recipes floating around that have multiple -dbg<br>
packages, but I can't see a great rationale for that. I also can't<br>
see a reason why you'd want debug objects/sources outside of the -dbg<br>
package, or something that wasn't a debug object or source inside the<br>
-dbg package.</div></blockquote></div><br></div><div class="gmail_extra">This seems like a step in the right direction to me.<br><br>I do think we should also pursue going a step further, adding the ability to automatically emit a per-binary-package -dbg package, rather than a single monolithic recipe-wide one. This would mean that adding dbg-pkgs to an image is cleaner and doesn't result in installing every sub-package of the recipe. This change you're proposing would make it easier to extend to potentially do this, possibly optionally.<br>
-- <br>Christopher Larson<br>clarson at kergoth dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior Software Engineer, Mentor Graphics
</div></div>