[oe] RFC feature/dep picking heuristics
Bernhard Reutner-Fischer
rep.dot.nop at gmail.com
Wed Jun 9 21:26:30 UTC 2010
On Wed, Jun 09, 2010 at 07:10:34PM +0200, Bernhard Reutner-Fischer wrote:
>Hi,
>
>These are independent.
>
>1) uClibc: redo configuration
> improve configury of uClibc
[]
>3) busybox: picking IPv6 per default is not up to the package
> first, busybox needs a better configury, like it's done for uclibc
> in 1).
> Second, who picks features and with what preference? packages? user?
> distro? machine? See FIXME in 1).
> This patchlet works around the real issue. Comments on how to tackle
> the underlying issue (or how it's solved elsewhere if it already is,
> i didn't see where/how ?) are _very_ welcome.
that FIXME in 1) reads:
index ee18fc8..b40fbf5 100644
--- a/conf/distro/include/uclibc.inc
+++ b/conf/distro/include/uclibc.inc
@@ -9,3 +9,11 @@ PREFERRED_PROVIDER_virtual/libintl_avr32 = "proxy-libintl"
PREFERRED_PROVIDER_virtual/libc = "uclibc"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}libc-initial = "uclibc-initial"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}libc-for-gcc = "uclibc"
+
+# libc settings
+DISTRO_FEATURES += "${@['', '
+nls'][bb.data.getVar('ENABLE_BINARY_LOCALE_GENERATION', d, 1) == '1']}"
+MACHINE_FEATURES += "${@['', ' bx'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1)
+== 'thumb']}"
+# FIXME: We enable IPv4 per default to avoid alot of breakage.
+# FIXME: Figure out an acceptable way to negotiate either
+# FIXME: desired features or hard requirements, either top-down or bottom-up.
+DISTRO_FEATURES += " ipv4"
Problem description:
[all of the following is rather obvious, please accept my apologies for
being redundant and possibly not 100% accurate to keep this brief]
Two realms: Hardware / Software
Both of them provide optional features or impose hard constraints on the
setup.
I) hardware/kernel/libc
Think arm thumb interworking bx or not any or all of them.
libc can use BX or fallback but only for thumb and for some
-mtune's (IIRC).
networking.
- none
- socket
- ipv4 (requires socket)
- ipv6 (requires socket)
- ipv4 || ipv6
nls.
- locales to generate (GLIBC_GENERATE_LOCALES; uclibc can use the same)
- several other options, namely wchar (think mc or mutt -- if forgot
which one -- which requires wchar if not patched)
II) packages
consider micro-base-image for libc=uclibc
consider recipes are equipped with HANDLE_FEATURE (big TODO, RFC).
assume HANDLE_FEATURE is auto-filled off configure.ac for the most
part.
that one selects sysvinit (bug per se but no relevant for now)
sysvinit uses inet_ntoa() or something to that effect
unconditionally -> not buildable since not base_contains HANDLE_FEATURE ipv4
Now my question is:
How can i fit a set of requirements to a set of config options that make
up a system (ideally without changing anything)?
If i have to change something, how should the decision-flow look like to
weight constraints against possibly provided features? What's the
precedence of the following parts:
o HW hard constraints
o HW soft constraints (optional features)
o kernel/Lowlevel hard constraints
o kernel/Lowlevel soft constraints (optional features)
o libc hard constraints (unconfigurable vs. configurable)
o libc soft constraints (optional features)
o package hard constraints (sysvinit requires ipv4)
o package soft constraints (optional features, like iptables/busybox ipv6)
TIA for clarifications or pointers to existing docs covering OE in this
respect && cheers,
More information about the Openembedded-devel
mailing list