| Summary: | native recipes should not care about DISTRO_FEATURES / MACHINE_FEATURES | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Jussi Kukkonen <jku> |
| Component: | core | Assignee: | Jussi Kukkonen <jku> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | meta.mr.watcher, meta.watcher, randy.macleod, richard.purdie, ross.burton |
| Version: | 2.3 | ||
| Target Milestone: | 2.3 M4 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
Jussi Kukkonen
2017-03-24 14:03:14 UTC
I think the main one we might care about in the native case is largefile which we'd always want turn on and we're likely deprecating anyway (in favour of always enabled). I can't see much of a case for not fixing the native list of features. I also agree that the libc ones are pretty much dead now. This really stretches my understanding of bitbake variables... documenting some details:
My initial approach is just to modify DISTRO_FEATURES (and if needed other variables) in native.bbclass. This turned out to be tricky:
* DISTRO_FEATURES = "<features we want for native>"
This will be overriden by at least DISTRO_FEATURES_append in any configuration as well as DISTRO_FEATURES_BACKFILL. This makes sense to me.
* DISTRO_FEATURES_forcevariable = "<features we want for native>"
Same results -- appends and backfill still get added to the list. I don't really understand why.
* anonymous python with d.setVar("DISTRO_FEATURES", "<features we want for native>")
This is so ugly but does ensure DISTRO_FEATURES is correct when tasks run. Unfortunately there are other anonymous python functions that do d.getVar("DISTRO_FEATURES") and end up getting the wrong value and modifying the build based on that.
On Richards suggestion I tried d.SetVar() in native_virtclass_handler(): this seems to work. My test case was: $ bitbake core-image-minimal # append " systemd" to DISTRO_FEATURES $ bitbake core-image-minimal With a native_virtclass_handler patch the second build had 135 tasks less to do. Sadly this doesn't show up in wallclock time: all the native tasks are done while glibc is still bottlenecking everything else. I'm sure there is a effect on cpu-time, I just didn't take note of it. I redid the tests with timing: $ bitbake core-image-minimal # append " systemd" to DISTRO_FEATURES $ bitbake core-image-minimal With master the second build was: real 15m23.533s user 135m19.244s sys 16m55.816s After patching: real 14m48.574s user 94m31.776s sys 13m54.560s user+sys difference is -44 minutes or -28% so definitely worth it. oe-core 731744d5538e315702be828e6f2bd556309dee07 solves this for DISTRO_FEATURES. oe-core 96c20c9df714cdf3f0e9461ec566c4f5d3bdb5f1 solves the native case for MACHINE_FEATURES. I *think* we're done with this. Closing! |