[Rock-dev] clang vs. typelib

Martin Zenzes martin.zenzes at dfki.de
Fri Jul 18 14:23:55 CEST 2014


So to make it more clear -- sorry if I'm a bit slow on this, but I like 
things black-on-white and crystal-clear:

In the moment (as far as i understand this) _all_ the records and 
typedefs from the whole include-chain triggered by a single 
"import_from" are stored in a database to be read by orogen. This allows 
usage of "struct timespec" although no one explicitly did "import_from 
time.h". This also allowed usage of "uint16_t" for properties although 
no one explicitly did "import_from stdint.h". This was caused by how 
gccxml works. Is this parse-and-store-everything still desired?

Makes the database large -- considering an eigen-based-example with ~200 
RecordDecls from system-headers and ~130 from eigen-headers.

Now, given a set of header files, the clang-based tool should:


- give all TypeDecl defined somewhere in the include-chain of the given 
header with its CanonicalName and the field-layout.
   - If this is a RecordDecl: For each field then do recursively: return 
the offset and BuiltinType or the CanonicalName and field-layout


- _all_ mappings "typedef" -> "CanonicalName" declared somewhere in the 
include-chain of the given header file.

- give all enum-values as strings


The outputs from different calls are then merged and collected in some 
typelib database, however this is organized...

Additionally reject Records with:
- pointers
- virtual functions
- references
- bitfields?
And warn about Records with:
- FieldTypes with architecture-dependent size, like int

Hm?


More information about the Rock-dev mailing list