[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Patches] Any remaining uses of option groups?
- To: Khem Raj <raj.khem@xxxxxxxxx>
- Subject: Re: [Patches] Any remaining uses of option groups?
- From: "Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>
- Date: Fri, 28 Jun 2013 22:00:21 +0000
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
system: OPTION_EGLIBC_CHARSETS OPTION_EGLIBC_IDN OPTION_EGLIBC_LIBM
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