[Rock-dev] clang vs. typelib

[Sylvain Joyeux]

Well. I personally was seeing it as a typelib plugin (living the
typelib package), which:
 - gets a set of headers
 - a set of options (mostly -I and -D)
 - some information about opaque types
 - and outputs a Typelib::Registry object with the (complete)
definition of all the types found in the specified headers.

The tlb importer is an example (in lang/tlb/importer.cc)

Sylvain

On Thu, Jul 17, 2014 at 2:42 PM, Janosch Machowinski
<Janosch.Machowinski at dfki.de> wrote:
> On 17.07.2014 13:30, Sylvain Joyeux wrote:
>>> We could also place references to TLB files in TLB files themself,
>>> and generate a TLB File per header file. In this case we could stop
>>> parsing anything, it there is already a TLB file for an included
>>> header. This could lead to big speedups, as we don't reparse all the
>>> headers over and over again.
>> Before going into modifications on the typelib side, I would rather
>> look into why it is so slow (and ask the clang mailing list how to
>> make it faster). Compiling a file that includes base/Pose.hpp and does
>> something with a base::Pose takes 1.61s on my machine, not 15s. Maybe
>> there would be a way to prune the traversal at the declaration level
>> since we really don't care about the inside of the methods.
> Definitely.
> This comment was more about the logic, how to convert the AST
> to Typelib later on. How would the final API to this tool look like ?
> - Give Types, and Headers, to put into a TLB ?
>   - Dump every Type from a set of Headers into a TLB ?
>
>      Janosch
>
>>
>> If we come to that, I would really really not break the self-contained
>> nature of tlb files, because it won't be manageable (if you update a
>> linked tlb file because a struct change but NOT the other ones, you
>> are breaking the type definitions). What would definitely be doable is
>> to save a self-contained TLB per header file in a cache folder and
>> have the clang importer merge these tlbs into the current registry
>> whenever an include is found. Now, how do you detect the includes
>> without traversing the AST ? And -- more importantly -- how do you
>> make sure that the cache is properly invalidated when some
>> include-in-include-in-include file gets invalidated ? Or when the
>> import options (such as the opaque list) gets modified ? Big can of
>> worms.
>>
>> Sylvain
>> _______________________________________________
>> Rock-dev mailing list
>> Rock-dev at dfki.de
>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>
>
> --
>   Dipl. Inf. Janosch Machowinski
>   SAR- & Sicherheitsrobotik
>
>   Universität Bremen
>   FB 3 - Mathematik und Informatik
>   AG Robotik
>   Robert-Hooke-Straße 1
>   28359 Bremen, Germany
>
>   Zentrale: +49 421 178 45-6611
>
>   Besuchsadresse der Nebengeschäftstelle:
>   Robert-Hooke-Straße 5
>   28359 Bremen, Germany
>
>   Tel.:    +49 421 178 45-6614
>   Empfang: +49 421 178 45-6600
>   Fax:     +49 421 178 45-4150
>   E-Mail:  jmachowinski at informatik.uni-bremen.de
>
>   Weitere Informationen: http://www.informatik.uni-bremen.de/robotik
>
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev