On Monday 03 September 2007, Karel Zak wrote: > Hi Mike, > > On Mon, Sep 03, 2007 at 11:08:21AM -0400, Mike Frysinger wrote: > > looks to me like all of the locale handling should be localized to the > > include/nls.h file right ? and that a few things havent been converted > > to that ? it also looks like in the ENABLE_NLS path, no one really > > explicitly pulls in locale.h, yet in the !ENABLE_NLS path, locale.h gets > > pulled in !? in other words, util-linux wont build anymore on a real > > system that completely lacks locale/nls support ... this about right ? > > this patch should fix that > > Deja vu :-) See: > > http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/590/focus=592 > > I agree that we need a better support for compilation without > locales, but from my point of view NLS != all locales stuff. The NLS > support is subset only. generally, yes ... i18n and l10n are different/sep topics, but is there any real need to differentiate them in util-linux ? i'm not terribly familiar with some of the tools, but are there any that really care about things like wide character inputs and such ? or is it all for localization ? > > Move all locale/nls related includes to nls.h and make sure they are only > > pulled in when ENABLE_NLS. When !ENABLE_NLS, don't include any > > locale/nls related headers and stub out setlocale() as well. > > Maybe we can add --disable-locales and --disable-nls option will be > subset of --disable-locales. > > BTW, is there any real life example for this change? sure, build it under uClibc or any other libc where you can sanely disable all i18n/l10n cruft -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
