[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: kconfig_compiler4
From:       Thomas Braxton <brax108 () cox ! net>
Date:       2005-12-26 19:32:42
Message-ID: 200512261332.42851.brax108 () cox ! net
[Download RAW message or body]

On Saturday 24 December 2005 08:15, Allen Winter wrote:
> Can you explain why the change?  kconfig_compiler already supported Int64
> and UInt64 types so I don't understand the need for eliminating Int/UInt
> types.  I think *adding* support for Int32/UInt32 may make some sense, but
> removing Int/UInt doesn't seem necessary, nor optimal.
>
> Regards,
> Allen

There were three integer related Items ItemInt/ItemLong/ItemInt64 that were 
reduced to two. ItemInt was renamed to ItemInt32 to be more specific about 
the size. ItemLong was removed because it could be ambiguous as to what size 
was wanted. When I proposed the change 
http://lists.kde.org/?l=kde-core-devel&m=113458437319830&w=2
I only got one response in 4 days 
http://lists.kde.org/?l=kde-core-devel&m=113490619202799&w=2
so I commited r489520.


I see the options for kconfig_compiler as:

1) add support for Int32/UInt32, don't remove Int/UInt
    - existing kcfg files work
    - generated code doesn't match the kcfg file, (U)Int items are changed to
      Item(U)Int32 in the generated code.
    - could remove Int/UInt before KDE4 is released, after all kcfg files are
      ported

2) add support for Int32/UInt32, remove Int/UInt
    - *all* kcfg files will need to be ported, simply replace Int with Int32
      everywhere.
    - generated code will match the kcfg file.

3) change KConfigSkeleton back to Item(U)Int instead of Item(U)Int32, use 
q(u)int32 as the templated type so that it is implicitly a 32-bit type.
   - existing kcfg files work
   - generated code will match the kcfg file.

Any option works for me, I just haven't had time to ask the list which option 
is wanted. Option #1 is a compromise between not breaking existing code and 
being more explicit about the size of the item, if the kcfg files are 
changed. Option #2 is the most far reaching, because all kcfg files will need 
to be ported, but it is the most explicit about the size of the item. Option 
#3 is the easiest, since Int has been used so far, it breaks the least code, 
but is the least explicit about the size of the item. IMHO the API should 
have been more explicit about the sizes of the integer items when it was 
designed, we wouldn't have this question now. Now we either live with the 
existing design or fix it. So, what does everyone think? I can commit for any 
option today. What do I commit?

P.S. Options #1 & #2 require changes to kcfg.xsd, to allow the kcfg files to 
be tested for validity, will this require a version change?

regards,
Thomas
[prev in list] [next in list] [prev in thread] [next in thread]