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

List:       kde-core-devel
Subject:    Re: kconfig_compiler4
From:       Allen Winter <winter () kde ! org>
Date:       2005-12-28 17:07:31
Message-ID: 200512281207.32588.winter () kde ! org
[Download RAW message or body]

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


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