On Fri, 2011-06-03 at 09:22 +0100, Richard Purdie wrote: > On Fri, 2011-06-03 at 14:47 +0800, Kang Kai wrote: > > From: Kang Kai <kai.k...@windriver.com> > > > > Migrate configurability from oe, try to shrink minimal image size > > > > The switch is in local.conf.sample, uncomment the line > > DISTRO_FEATURES_EGLIBC = "" > > and write what options you want to enable. > > > > If want to disable locale-code charsets or locales, you have to uncomment > > PACKAGE_NO_GCONV = 1 > > Because without this, it fails on package_do_split_gconvs in > > libc-package.bbclass > > I have some comments: > > a) I think these should become flags in DISTRO_FEATURES with an > "eglibc-" prefix so something like "spawn" would become "eglibc-spawn"
I'm not sure I agree with that. Some, maybe most, of these flags are not really specific to eglibc (in concept, even if eglibc is the only package which respects them at the moment). Some of them (eg ipv6) are already established DISTRO_FEATURES which are used in various other places; others, including perhaps your spawn example, are specifically bound to the contents of the C library but could equally well be respected by uclibc. So, for the latter group, I think just "libc-spawn" would be better than "eglibc-spawn". Maybe "libc-has-spawn" would be even better, to make it clear that we're talking about a feature within libc and not a specific variant of libc. In an ideal world there would also be a mechanism for packages to declare that they require a particular feature from libc, i.e. a recipe could say DISTRO_REQUIRED_FEATURES = "libc-spawn" and it would then be a configuration error to try to build that recipe for a distro that doesn't admit the necessary things. > b) I think we need to create a local.conf.sample.extended which has > information about more advanced settings a user can configure. I don't > want every setting in local.conf as standard as it gives the user the > impression they have to change them which they don't. Some existing data > in local.conf.sample can be moved over. Agreed. > c) The code triggered by PACKAGE_NO_GCONV should also trigger if you set > the appropriate eglibc- feature flags automatically. Having two > variables you have to keep track of the combinations of is just plain > wrong. They should be controlled by one flag only. If there is generic > packaging code that handles these we might not need the "eglibc-" prefix > for those options. I didn't fully understand the commentary around PACKAGE_NO_GCONV so I'm not sure that I have a meaningful opinion on that one yet. As far as I know, though, there is no generic packaging code for gconvs (unlike locales, which are handled generically in package.bbclass) but, again, the concept of gconvs is not eglibc specific and there are other libs which might provide them. p. _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
