[Kde-bindings] SMOKE feature proposal: making a distinction between wrapped headers and dependable headers

[Dimitar Dobrev]

    Hi all,

    I' d like to propose a change in the behaviour of SMOKE. Currently it treats all headers it parses the same way, regardless of whether they are wrapped or simply dependencies. This leads to the following problems:
    1. Repetition of functions and enums
        All functions and enums of core modules are generated in each module that depends on this core. Arno, with some help from me, has been working on some changes that load the already compiled SMOKE libs and for each function or enum check if it is already there and if so, skip it. This works with the exception of SMOKE KDE, with which Arno has some problems. Besides, I strongly believe this is only a workaround because these functions and enums should've been dropped when still parsing the headers.
    2. Repetition of classes
        Classes do not actually repeat but this is only because the requested classes are explicitly defined in the smokeconfig.xml. I think this enumerating of classes is a bad idea because it kills the whole point of automation, in theory, and creates the need of manually reviewing the API of the bound lib with every new version, in practice (Qt 5, for example). Therefore I attempted some changes causing the generation of simply all public classes in the headers, with the exception of some internals found by trial and error (the only way I am aware of). For that purpose I extended Arno's changes from 1. to check for repeating classes as well. The result was that those black lists of internals of core modules had to be repeated in every smokeconfig of dependant modules because as the internals were not generated, the check for repetition could not find them and the logic attempted to generate them in the new module. While there may be some kind of
 workaround for that, I am convinced that the need for a second workaround is proof that the problem should be solved another way.


    I would like to try and implement this distinction in headers.However, to determine the best place to introduce the changes, I need to know in details the whole process of parsing headers and extracting types and members from them. So I'd like to ask everybody familiar enough with SMOKE to lay itout as much as they can. Thanks.
    

    Dimitar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20121228/29ee05b0/attachment.html>