CastXML integration #66
Commits on Mar 17, 2016
-
More idiomatic than #clear w.r.t. Ruby containers
-
copy metadata in minimal(registry)
It was done only in minimal(typename)
-
fix TypeBuilder w.r.t. template-like constructs
The type builder name parsing would fail on e.g. /a/type</int[32]> This is currently only used in the tlb importer, which once-upon-a-time was able to load TLBs where e.g. arrays would not be defined. This is not the case anymore (which is probably why we have not hit the problem ... yet)
-
-
Debian (Testing) has changed the name from gccxml to gccxml.real This needs this hack. If gccxml.real is present in path use this instead of gccxml.
-
gccxml: remove the 'absolute' flag to the cxx_to_typelib conversions
It was completely buggy, and is therefore obviously unused.
-
gccxml: unify the determination of type names without using the 'dema…
…ngle' field The namespaces were already resolved by going through the context nodes recursively. This has become the way to go for castxml as well, and is backward-compatible with gccxml, so let's just use this method.
-
gccxml: remove some of the normalization hacks
Basically, this moves the translation of /std/basic_string to /std/string and /std/vector<..., allocator> to /std/vector<...> higher up.
-
-
gccxml: fix calling castxml and use it by default
castxml does not behave exactly like gccxml w.r.t. file resolution Basically, only the toplevel file is referred to in the output instead of being "exact" Funnily enough, that's exactly what orogen needs (the orogen_include) stuff. Maybe it's time to drop the performance hack (put as much as possible in a single header) for the benefit of performance. For now, resolve each header one by one at least until castxml works
-
-
gccxml: fixed ivalid return in case a typedef is loaded before a type…
… definition In the old case a string was returned which makes the importer belive that a type could be resolved. In the second run the type was ignored. Fixed this inconsistency by retuning nil when a ignored node is created
-
gccxml: fix handling of various anonymous C++ constructs
Namely: - anonymous namespaces - anonymous classes
-
gccxml: re-integrate handling of qualified types
Was left out, but re-add it for consistency with the clang importer.
-
-
-
clang: extract opaques from the provided registry, as the gccxml impo…
…rter already does
-
-
-
cxx,test: expect the importers to alias the full vector or string nam…
…e to the short typelib name, not some already shortened version
-
cxx,test: remove eigen dependency from cxx importer tests
Signed-off-by: Martin Zenzes <[email protected]>
-
ruby,test: add a 'runner' script to easily run tests
It's basically a command-line to run 'minitest', with the added functionality of setting up the include path properly and load test_config.rb
-
gccxml: move type name normalization as late as possible
This applies to vectors and template type names which point to typedef'd, opaques or vectors
-
-
gccxml: implement setting the cxxname metadata
It is implemented in clang, and is going to be useful for orogen Note that the final format generated by gccxml does NOT match clang. It instead matches the syntax that one would expect to do code generation.
-
cxx,test: test the metadata fields as well
It required to update the target tlbs: - the final format for the cxxname field differs from the one used in the clang importer - source_file_line can robustly be tested only for files included in the test dir, system files will change from compiler-to-compiler and system-to-system - in classes.hh, it seems that the clang importer is setting the base_classes metadata for opaque classes. That's not implemented in gccxml and I really don't see the use case (since opaques, are you know, opaques)
-
-
-
cxx,test: do not explicitely remove standard C++ types in tlb_cxxgen
This should be handled by the importer(s) themselves
-
cxx,test: in cxx_tlbgen, write the TLB in the test dir directly, but …
…under a new name
-
cxx,test: support having importer-specific expected tlb files
One can add a .tlb.IMPORTER_NAME file that is specific to the importer, in which case the test verifies that the loaded registry has all tests for the common registry, and complete equivalence for the loader-specific registry This is because the clang importer currently does not support pointers, but gccxml/castxml does, and I don't want to make it a strong requirement just yet.
-
cxx,test: fix loader selection
Some tests where still selecting their loader based on the TYPELIB_CXX_LOADER envvar, which goes contrary to what we actually want.
-
-
-
cxx,test: fix minor discrepancies between castxml and gccxml modes
After this commit, both gccxml and castxml pass the suite
-
-
-
-
-
-
-
-
-
-
gccxml: workaround weird gccxml handling of negative integer paramete…
…rs in template Negative integers (e.g. -2) are represented as -0x000000N (e.g. -2 is -0x000000002)
-
castxml: do not mandatorily add '-std=c++11' to the castxml command line
One should add it through the TYPELIB_CASTXML_DEFAULT_OPTIONS environment variable
-
castxml: remove EIGEN_DONT_VECTORIZE
clang/castxml can handle the vectorization instructions just fine
