Additions to kconfig_compiler for enum types

[David Jarvie]

On Monday 19 February 2007 17:52, Aaron J. Seigo wrote:
>On February 19, 2007, David Jarvie wrote:
>> this. However, if externally defined enums are introduced (as below), I
>> could accept the restriction that elements must have unique names where the
>> enums are defined in the settings class, since there would then be the
>> option to name the elements independently elsewhere. Ruling out duplicate
>> names, we could then simply declare the enums without embedding them in
>> special enum classes:
>
>the question will be how many kcfg files would need to be updated with this 
>new restriction in place. hopefully few to none =)

I'm not proposing to change the way that automatically named enums work.
Only when the enum name is specified with <choices enum="..."> (without
"::") would the enums be declared as simple enums rather than embedded in
their own classes. So no existing code would need to be changed.

I'd prefer to see the facility to have elements with the same name in
different automatically declared enums retained - having to avoid duplicates
would to my mind impose artificial restrictions on the developer's freedom
to use the best names for the elements.
 
>> I think that the presence of "::" in the names of enum elements could
>> specify that an externally defined enum should be used. 
>
>that would make a good deal of sense... i like it

As I proposed in my later email (the first one went astray for a few hours,
so I rewrote it), "::" would only be specified in the enum name, i.e. in
the <choices> element. The enum elements in <choice> wouldn't have "::".

>> Enums are already defined automatically by KConfigXT - I don't see that
>> extending this to specifying the enums' names is a departure from its
>> purpose.
>
>oh, i know it does this currently; i'm just not sure it was the best way to go 
>about doing it in the first place =)

--
David Jarvie.
KAlarm author & maintainer.
http://www.astrojar.org.uk/linux/kalarm.html