Looking for clarification and ideas on %ConvertToSubClassCode for PyKF5
Shaheed Haque
srhaque at theiet.org
Thu Jan 5 09:27:39 UTC 2017
Hi all,
The effort to generate PyKF5 semi-automatically (to replace PyKDE4) is
making some headway but I am uncertain as to how best to tackle the problem
of %ConvertToSubClassCode. The first clarification question is to check I
have understood correctly that the basic process for designing
%ConvertToSubClassCode is:
For each .sip file in a SIP module
For each type in the .sip
For all known subclass trees
Generate a fragment of code (like the sample below)
Is that right?
Assuming that is correct, the second question is about how to implement the
above. In the PyKDE4 days several thousand lines of code like this were
lovingly hand-crafted:
%ConvertToSubClassCode
// CTSCC for subclasses of 'KConfigSkeletonItem'
sipType = NULL;
if
(dynamic_cast<KCoreConfigSkeleton::ItemBool*>(sipCpp))
sipType = sipType_KCoreConfigSkeleton_ItemBool;
else if
(dynamic_cast<KCoreConfigSkeleton::ItemDateTime*>(sipCpp))
sipType = sipType_KCoreConfigSkeleton_ItemDateTime;
else if
(dynamic_cast<KCoreConfigSkeleton::ItemDouble*>(sipCpp))
sipType = sipType_KCoreConfigSkeleton_ItemDouble;
else if
(dynamic_cast<KCoreConfigSkeleton::ItemInt*>(sipCpp))
{
sipType = sipType_KCoreConfigSkeleton_ItemInt;
if
(dynamic_cast<KCoreConfigSkeleton::ItemEnum*>(sipCpp))
sipType = sipType_KCoreConfigSkeleton_ItemEnum;
}
...
(I have de-duplicated this by hand, and I still have over 1000 lines of
code). Now I have over 2000 .sip files across over 100 components that make
up PyKF5 and a minor nightmare in prospect :-). It seems to me that I have
several manual options:
1. Ignore the problem at this level, and only manually create
%ConvertToSubClassCode on an as-requested basis, release-by-release. (On
occasion, I may be able to use the PyKDE4 code as a starting point, but the
shape and details of the type hierarchy in PyKF5 is often rather different).
2. For each of the 100+ components, don't release the component until
the work is done.
Neither of these is attractive from a user perspective, and perpetuates the
problem from a maintainer perspective. The other way forward might be some
kind of automation in the SIP generation automation layer:
1. Let's say that the presence of RTTI is a given.
2. We know we are dealing with a Qt-like system including all its magic
macros and the like.
3. We can run some kind of offline analyser (the SIP generator uses
libclang, and can either operate on a single .h file at a time, or we can
even run over a whole directory hierarchy if needed).
Has anybody attempted this before? Any other suggestions? Can we do
something at runtime?
All input welcome...
Thanks, Shaheed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20170105/4a37850e/attachment-0001.html>
More information about the Kde-bindings
mailing list