Changes between Version 4 and Version 5 of WikiStart/OngoingWork/TypelibImporter


Ignore:
Timestamp:
12/10/15 15:00:38 (3 years ago)
Author:
sylvain.joyeux
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WikiStart/OngoingWork/TypelibImporter

    v4 v5  
    8787 * yeah, while I would like to write the xslt I see that this wouldn't be feasible to maintain ;-) 
    8888 
     89== Sylvain: answers == 
     90 
     91 * what is not so nice in the moment is the way of orogen+typelib working together: tlb-generation (aka: write text-file on harddisc) and creation of tlb-registry object (aka: loading this file) is not clearly separated. contrary, orogen goes and modifies the tlb-files created by typelib -- packaging nightmare. 
     92   - I really don't understand what you are getting at with this "generation" vs "object". Whatever you do, you should use an internal data structure that then gets marshalled into text (generating text directly without an internal structure ? <insert sardonic laugh>). So, bottom line, the cleanest is to build a typelib registry object (or any other internal data structure that is a faithful representation of a tlb) and then ask to marshal it into a TLB. Yes, it does sound like "using typelib". 
     93   - Typelib does not know about build systems, about how orogen generates its code and so on, only orogen does. Which is good. The only problem I personally see is that the XML gets modified (for opaques) instead of using metadata (which got added a lot later) 
     94   - there are a few things that could really be removed from orogen and moved into the importer, as e.g. the C++ type name determination - which the castxml and clang importers do. 
     95 * so: have a well-defined and self-contained file format ("tlb") for typelib to load and derive its c++ and ruby objects during runtime 
     96   - this is already what typelib does. What it should NOT be is a format for orogen-specific code generation bits 
     97 * why is the resolution of import header an orogen issue? how can orogen, miles away from parsing c++ code, decide on which string to put into the #include "" statement to get a needed declaration? couldn't some tlb-generator, who is parsing c++ code, decide this more easily? 
     98   - orogen is miles away of parsing C++ code, but is not miles away from C++. It is *generating* C++ code, it knows about C++ and needs to know about it. 
     99   - there's two parts in the import header resolution. The first one is to determine which toplevel header a type comes from, which indeed could (and probably should) be resolved by the importer. The second bit is to determine which pkg-config package provides that header, which is specific to orogen. 
     100