Re: [OE-core] RFC: automatic -dbg splitting
On Tue, Oct 7, 2014 at 3:25 AM, Burton, Ross wrote:
> On 11 June 2014 20:10, Burton, Ross wrote:
> > I know there are recipes floating around that have multiple -dbg
> > packages, but I can't see a great rationale for that. I also can't
> > see a reason why you'd want debug objects/sources outside of the -dbg
> > package, or something that wasn't a debug object or source inside the
> > -dbg package.
>
> So last night I resurrected this patch and did an oe-core world build
> with a small change to clear FILES_${PN}-dbg before automatically
> populating it. The results were interesting and invalidated my two
> assumptions:
>
> 1) Adding files that are not debug symbols or sources to -dbg packages
> is done: both gcc and glib add Python code for gdb to execute and the
> -dbg package is the obvious location for it.
>
> 2) A recipe having multiple -dbg packages is sensible for eg Qt4,
> which if all the debug information is put into a single package
> results in a 367M package, expanding to 1.1G on disk.
>
> So I've a proposed change to the logic:
> * If there are multiple names in PACKAGES that match *-dbg, then don't
> do automatic debug packaging
> * The default value for FILES_PN-dbg in bitbake.conf should be empty,
> and recipes can extend it as required (e.g. gdb Python scripts) with
> the automatic debug packaging extending FILES_PN-dbg.
For what it's worth, this behavior seems quite sane to me.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: automatic -dbg splitting
Hi all,
On 11 June 2014 20:10, Burton, Ross wrote:
> I know there are recipes floating around that have multiple -dbg
> packages, but I can't see a great rationale for that. I also can't
> see a reason why you'd want debug objects/sources outside of the -dbg
> package, or something that wasn't a debug object or source inside the
> -dbg package.
So last night I resurrected this patch and did an oe-core world build
with a small change to clear FILES_${PN}-dbg before automatically
populating it. The results were interesting and invalidated my two
assumptions:
1) Adding files that are not debug symbols or sources to -dbg packages
is done: both gcc and glib add Python code for gdb to execute and the
-dbg package is the obvious location for it.
2) A recipe having multiple -dbg packages is sensible for eg Qt4,
which if all the debug information is put into a single package
results in a 367M package, expanding to 1.1G on disk.
So I've a proposed change to the logic:
* If there are multiple names in PACKAGES that match *-dbg, then don't
do automatic debug packaging
* The default value for FILES_PN-dbg in bitbake.conf should be empty,
and recipes can extend it as required (e.g. gdb Python scripts) with
the automatic debug packaging extending FILES_PN-dbg.
Any thoughts?
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] RFC: automatic -dbg splitting
Hi, So yet again I was wrestling PACKAGES and FILES in an attempt to get everything in the right place, the latest complication being ptest and where they are in the PACKAGES chain making correct splitting tricky. Again I wondered why debug packages need explicit FILES, and did a quick hack as a proof of concept to put split debug objects and source code into PN-dbg automatically, instead of through explicit FILES. This hack is at best: it clears FILES_PN-dbg in bitbake.conf and as it executes do_package FILES is set for each file it handles. As PN-dbg is at the beginning of PACKAGES it takes the right files before other packages, apart from when other =+ is used as in ptest... so my original reason for looking at this is still a problem. This is in ross/debug in poky-contrib, fwiw. Before I look at this again and avoid FILES entirely, I should check that my assumptions are valid in the greater community. My big assumptions here are that 1) every recipe has a single -dbg package, 2) every debug object belongs in that -dbg package, 3) only debug objects and sources belong in that -dbg package. I know there are recipes floating around that have multiple -dbg packages, but I can't see a great rationale for that. I also can't see a reason why you'd want debug objects/sources outside of the -dbg package, or something that wasn't a debug object or source inside the -dbg package. Anyone disagree? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
