On 4/29/13 3:10 PM, Richard Purdie wrote:
On Sat, 2013-04-27 at 17:15 -0400, Chris Larson wrote:
On Thu, Apr 25, 2013 at 7:12 AM, Phil Blundell <[email protected]> wrote:
I'm not quite sure what the right way to fix (2) is. I
suppose in an
ideal world the -dbg packages would be separated in the same
way the
parent binary packages are, but that doesn't look entirely
straightforward to arrange.
I had implemented something along these lines back in oe classic, when
I was at MontaVista. See
http://git.openembedded.org/openembedded/tree/classes/package_dbg.bbclass for
that implementation. I haven't touched it or tried using it in some time,
however.
I have to admit I've been wondering if we shouldn't overhaul the -dbg
part of the system a bit. There are a few things I've been wondering
about:
a) Should we ditch FILES_${PN}-dbg and have it auto constructed from
any .debug directories? This would be a rather nice automation/cleanup.
I can't see a pressing reason not to do this.
b) Consider splitting it to a -dbg package per package where there are
debug files as per above. There are pros and cons to this and I'm torn,
see c).
c) Consider splitting the debug source into a separate package. If we
did do b), the question is where should the sources go?
I think that the proposal for automatically generating a -dbg per regular
package is a good one. Then the sources can go into -dbg-source or something
similar.. (source-dbg so it still ends in dbg).
This will give us the most flexibility to limit the amount of code that HAS to
be installed onto a target to do basic crash dumping, if not full debug on the
target.
In the bigger picture we have various dependency chain issues as the
-dbg and -dev dependency changes are horrible. The question has always
been whether X-dbg or X-dev should be usable to pull in sensible
dependencies.
Thinking about the scenarios you might use these in:
a) A binary from package X segfaults. You want to get good gdb data for
why. You therefore install X-dbg. X links against Y. You therefore want
the symbols/code for Y too so you can trace into the problem which may
be in Y.
This is the one that is sketchy to me. I think the rrecommend is a good idea
here. If you recommend everything that the main package (that you based on)
needs that you should be able to do this. By splitting the size of the -dbg
into smaller units then the -dbg recommends should be limited as well. I say
recommend vs depend simply because the there are cases where I only want the
symbols for one binary, I don't care about it's dependencies.
The question though is should the source also be a recommend or suggest?
b) You want to compile against X, you install X-dev. You expect anything
X needs to link with (e.g. through any .pc file) to also be present.
c) You want to rebuild X and hence install X-dev to ensure the build
dependencies are present.
I think this very much reasonable on the -dev front. If I install a -dev
package, I expect the system to be able to compile software without additional
manual steps.
d) There was once an idea that you could do something like install
core-image-minimal-dev to get the equivalent of core-image-minimal with
dev-pkgs. I think we've found better ways to do this kind of thing now?
In a/b/c, the usability fail is if you try to gdb/compile, find a
dependency missing, install it and repeat this cycle several times over.
Ya, the issue though is there are more use cases for debug then for the -dev
case. So I'm comfortable with slight differences in behavior between the two.
--Mark
Given d) is dead, thankfully, does that let us rip some code out and
improve the dependencies?
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
