kconfig_compiler4

[Allen Winter]

On Monday 26 December 2005 14:32, Thomas Braxton wrote:
> 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?
> 
Thomas,

How about if we eliminate (U)Int64?  Just use (U)Long types in *.kcfg files to mean "a really big integer" type.

I'm not sure why we should be specifying the number of bits of a configuration type.

Int types should eventually convert into the machine wordsize and Long types to the biggest integer
you can get on the machine (which might be long long on some systems).

My 2cents,
Allen


-- 
Let's Keep the Political Talk Out of KDE PLEASE