Re: [patches] Option group headers

[Mark Mitchell <mark@xxxxxxxxxxxxxxxx>]

Jim Blandy wrote:

> I'm thinking of having <features.h> #include another installed,
> generated header that defines or leaves undefined macros named
> __OPTION_x__ for each option group x.
> 
> Is this a losing idea, or a good one?  I'm definitely a butcher at the
> moment; I hope the folks here can help me become a bit more like a
> surgeon.

I think it's a reasonable idea.  (Stylistically, I'm a fan of macros
defined to zero/one, rather than defined/undefined, so that you can test
them with "if" as well as "#if", but that's just nit-picking, and
following GLIBC's existing style is probably a better call.)

However, since one of our goals is binary compatibility with GLIBC, we
shouldn't *require* that you build with an accurate <options.h> header.
 In particular, you should be able to build your application with full
EGLIBC, then configure it down, and not have to a rebuild or relink.

I don't think we have to worry about the other direction; i.e., building
an application that uses wide-characters with an EGLIBC that was
configured without that.  If distributors want to distribute EGLIBC
headers that work with all EGLIBC configurations, they can do so by
turning all the option groups on and installing the headers.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@xxxxxxxxxxxxxxxx
(650) 331-3385 x713