RFC: problems with splitting up kdebase

[Thiago Macieira]

David Faure wrote:
> This is why I really prefer the approach of
> generating xml from some C++ header, and then generating
> adaptor+interface from that xml. Interesting, isn't it, it's exactly
> how dcop idl worked :-)

I know, I designed the tools to work like that. The original name of the 
tool was dbusidl2cpp. :-)

The difference being that the file you process is an actual adaptor. So 
you can write your class in C++, *use* it and generate the XML and the 
interface from it. The generated adaptor is the same class, with the 
small difference that it will contain the XML embedded as a classinfo.

>This way the "source" of it all is a language we know, C++, instead of
> some strange xml.  (If anyone wonders how to do this: cf
> kdelibs/kio/misc/kwalletd; there the xml is generated from a
> hand-written adaptor, but it could just as well be generated from the
> real class instead, kwalletd.h).

Yep. However, parsing the C++ file like this is lacking some features. For 
instance, it doesn't parse unknown types, for the simple reason that we 
need to know what they expand to.

My current idea is to add a "glue" file that will be parsed along and will 
contain the necessary info.

>> In this stage in development, I agree that causing errors is best, to
>> catch porting errors. But once the interface is established and
>> published, there's no need to continuously update the XML file.
>
>Why? Surely you will add more methods later. Nothing is "one time only".

Only if the XML file you keep is a "copy".

If you're using an installed copy, the auto-generation will break as soon 
as the interface is updated. The existing C++ class won't implement all 
methods.

>> In special, the XML description can diverge from the implementation.
>
>How?

Like I said above. And if you don't auto-generate at compile-time, you 
could just update the XML file whenever you wanted, but regenerate the 
adaptor only when you were implementing the new methods.

>Agreed. But note that the "original" can be updated at some point.


-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070627/bfa45b31/attachment.sig>