Re: [patches] First cut at simple option group support

[Richard Sandiford <rsandifo@xxxxxxxxxxxxx>]

Jim Blandy <jimb@xxxxxxxxxxxxxxxx> writes:
> One concern that was expressed in internal CodeSourcery discussion is
> that while this code resembles the Linux and uClibc configuration
> systems, it differs from it sufficiently to invite confusion: whereas
> in Linux leaving a boolean or tristate variable unset omits the option
> group, in the present EGLIBC option group system, leaving a variable
> unset enables the option group.
>
> This was a deliberate choice.  By having eglibc.config list only those
> option groups that should be omitted, we make it easier for developers
> to avoid breaking binary compatibility as EGLIBC evolves: re-using an
> old configuration file with a newer EGLIBC will never shrink the set
> of available functions.  It also makes the default configuration ---
> all option groups included --- more obvious: it's an empty or omitted
> eglibc.config file.
>
> That explained, we'd be happy for the discussion to continue here.

As the person who raised this objection, I'd like to state my case here.
I think that option-groups.mak should include a default configuration
file that sets every option to the "full GLIBC" state.  For the style
of options we're expecting to provide in the near future -- where options
turn normal GLIBC features on and off -- this amounts to setting every
option to "y".  We should then include the user's configuration file.

IMO, this system retains the main benefit of the posted patch -- it allows
people to create override-only configurations -- while having some extra
advantages:

  - It means that the two configuration files taken together would
    provide the same interface as the configuration files used by
    other projects like linux, uClibc and busybox.  It will be less
    confusing for folks who work on both projects.

  - I think it scales better to non-boolean macros.  E.g. if we ever
    have a numerical configuration variable, we could simply put the
    usual GLIBC value in the default configuration file.  With the
    current scheme, we would need to cope with an "unset" value as
    well, and use some other means of converting an unset variable
    into the default value after the configuration file has been read.

  - The default configuration will provide a quick source of reference
    for the available options.  If we ever do have non-boolean options,
    it will be a quick source of reference for their default values.

  - It avoids non-empty configuration variables from accidentally
    leaking in from the environment, and thus turning GLIBC features
    off unexpectedly.

  - If we make option-groups.def a true Kconfig file, users who want
    to use the kernel UIs to select options could probably do so fairly
    easily.  (Of course, we can't import the kernel UIs ourselves because
    of copyright issues.)

  - It avoids the duplication of having "foo-y" and "foo-" for every
    configuration-sensitive make variable.

Richard