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 <[email protected]> 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 >> [email protected] >> 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: [email protected] > > Weitere Informationen: http://www.informatik.uni-bremen.de/robotik > > _______________________________________________ > Rock-dev mailing list > [email protected] > http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
