| Summary: | Consider limiting the scope of depchains to runtime deps to shrink SDK size. | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Christopher Larson <kergoth> |
| Component: | core | Assignee: | Unassigned <unassigned> |
| Status: | NEW --- | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | Medium | CC: | meta.mr.watcher, meta.watcher, randy.macleod |
| Version: | unspecified | ||
| Target Milestone: | Future | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Don't know | |
I'm thinking *if* this is worth looking into at all, it could be worth trying a prototype of:
1. make the rdep handling map back to recipe names rather than adding -dev to runtime deps, to make it more fully featured
2. make RDEPENDS_${PN}-dev default to including every emitted binary package, not just ${PN}, then the user could pare that down if they choose to
3. limit the scope from the current 'rdeps of every binary package' to 'rdeps of every package listed in RDEPENDS_${PN}-dev'
4. remove DEPENDS handling, keeping just the now-more-capable-RDEPENDS-handling
5. add some automatic rdeps to -dev, i.e. if it ships a .pc, rdep on pkg-config, that should fill in the gaps a bit for the bits lost by dropping DEPENDS
Bulk move from 4.99 or 0.00 to 5.99 |
Currently, we don't distinguish between the dependencies needed to build a project (i.e. ncurses) and those needed to develop against that project. For example, there could be many deps needed to build ncurses which aren't needed to link against it. Let's say we alter RDEPENDS_${PN}-dev to dep on a lib sub-package rather than the main package, so as to avoid pulling in a ton of tools and whatnot that aren't needed for development, but then depchains pulls in everything in DEPENDS anyway, along with every rdep of every sub-package, rather than only traversing the rdeps listed in RDEPENDS_${PN}-dev. This limits our ability to control what's really needed to develop for a project, unless we disable depchains entirely. It'd be nice to have an option to just add rrecs on the recipe dev packages for any binary packages my -dev depends on. Also, pkg_addrrecs isn't ideal, it blindly adds -dev to runtime dependencies, even though -dev is recipe-wide. Since we're running at do_package-time, we should be able to use pkgdata to map the rdeps back to the recipes and add -dev to those, so my hypothetical case could have RDEPENDS_${PN}-dev pull in ${PN}-lib, and then RDEPENDS_${PN}-lib mapped back to the recipes providing those packages, and dep on the ${PN}-dev of those recipes. 1. Enhance the rdep handling to map back to recipes 2. Consider changing the default behavior, or at least add options to control the default behavior, of package_depchains, to allow us to limit the scope to what's really needed to develop. Either that, or anyone who cares can start manually populating RRECOMMENDS_${PN}-dev :) This originated with noticing that installing dev-pkgs installed more than just -dev packages, it also sucked in a ton of sub-packages from both the requested packages and their deps, so a lot of tools and whatnot get installed which aren't needed for development at all. I'm a bit torn on this one. Err'ing on the side of including everything makes a certain amount of sense, to avoid risk of having a non-functional development environment, and an argument could be made that anyone doing on-target development shouldn't care about size. On the other hand, this bloats up our SDK/ADT/etc by sucking everything into the sysroot, so limiting the scope somewhat, while keeping the core of the functionality, could make a certain amount of sense. I think it could be worth experimenting with removing the DEPENDS bits, but keeping the RDEPENDS-for-all-binary-packages bits.