[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Patches] Any remaining uses of option groups?

On Fri, 28 Jun 2013, Khem Raj wrote:

> Yes, I have had this on my things to-do list for long since 2.17 was released. I have now cleaned them
> up on top of trunk and would be sending them to the list very soon after some
> testing on various architectures.

Thanks.  I strongly advise those caring about option groups to test with 
each option group disabled after every merge from FSF to EGLIBC trunk, not 
just for releases, to detect bitrot quickly.

(I still intend, in any case, to remove at least the 
OPTION_POSIX_REGEXP_GLIBC glibc option group as being fundamentally 
ill-conceived - option groups should correspond to well-defined sets of 
functionality, not to a choice to use an old, buggy implementation of a 
piece of code with no clear definition of what features are being 
disabled.  In addition, I believe the following option groups are 
*pointless* because they just disable some subset of the installed files 
and so can just as well be implemented entirely outside of glibc by being 
selective as to which files installed by glibc get installed on the target 
OPTION_EGLIBC_LOCALES.  You probably want to be selective *anyway*, given 
that the headers and static libraries are useless on your typical embedded 
system but are needed in the sysroot during development.)

Joseph S. Myers
Patches mailing list