[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, 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 
into glibc.

Joseph S. Myers
Patches mailing list