[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Patches] Any remaining uses of option groups?
- To: Denis Zaitceff <zaitceff@xxxxxxxxx>
- Subject: Re: [Patches] Any remaining uses of option groups?
- From: "Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>
- Date: Fri, 28 Jun 2013 15:09:20 +0000
On Fri, 28 Jun 2013, Denis Zaitceff wrote:
> The list contains my homegrown additions, too (like
> OPTION_EGLIBC_FORTIFY). Yes, the size of libc.so is not cut down
> dramatically, but if some things are not used _at all_ and if they can
> be excluded, then why don't exclude them?
Because having extra ways to configure things means a combinatorial
explosion of different feature combinations, and the disadvantages (to the
project dealing with the whole set of combinations) may now outweigh the
advantages (to someone dealing with only one particular set of features).
> And without option groups, what will be the main difference between
> eglibc and glibc?
As I said in <http://www.eglibc.org/archives/patches/msg01268.html>,
having a separate source tree for EGLIBC was a workaround for a problem
that no longer exists. Beyond maybe some compatibility code, the
differences should all go away, and lack of sufficient interest in a
difference to merge it to glibc (possibly reworking the implementation in
the process) may end up being taken as evidence that the difference is no
longer sufficiently useful and should be reverted from EGLIBC.
I don't consider maintaining option groups long-term as a divergence
between glibc and EGLIBC a sensible option. The sensible options are
removing the feature or someone sufficiently interested in it getting it
Joseph S. Myers
Patches mailing list