Shaheed,
One issue I am struggling to find a good solution for is to generate an accurate list of the objects (classes, functions, variables etc) in a given header file in order to populate the selection .XML.
that option exists, but apparently no-one has ever used it, as it is clearly broken. :P It should be: <selection> <class pattern="*" file_name="SomeHeader.h" /> <enum pattern="*" file_name="SomeHeader.h" /> <function pattern="*" file_name="SomeHeader.h" /> <variable pattern="*" file_name="SomeHeader.h" /> </selection> genreflex exists for backwards compatibility, underneath it's rootcling, which accepts this: #pragma link C++ defined_in "SomeHeader.h"; and that does work ... I'll dig a bit, see what goes wrong with genreflex; should be no more than proper rule registration. But if not restricting selection, what errors are you seeing?
Short of running Clang directly to generate the names, what options do I have?
If using PyPy (not yet CPython), you can load all files in a header, include that, and simply start looping over dir(cppyy.gbl). (This is one of a set of things that I still have to equalize between PyPy/cppyy and CPython/cppyy.)
Also, as I looked around for approaches to this issue, I noted that the cppyy backend v610 5 source code has a "getAllClasses" whereas PyPI has 6.10.0.2.
That getAllClasses was a hack for compatibility reasons that doesn't do what the name supposes it does: there can always be more classes that could be found through a mapping file, but haven't yet. Hence a functional dir() is a better approach.
I'm not sure of the mapping of versions, but what is the cadence for updates to PyPI?
It's only since a few months that I split everything off into a standalone package (there's a reason the first version digit is still 0) and I'm still sitting on some restructuring to separate things that update often from things that don't. The backend part is expected to update every half year or so, once packaging stabilizes (that's the cling schedule).
[1] https://marc.info/?l=kde-core-devel&m=150464598710128&w=2
Just a few minor points in response to that message. E.g. yes, overloads end up as a single Python function, but if you don't want that, then you can use __disp__("signature") to pick out the ones you want. Those are first-class objects, and allow any kind of restructuring that Python allows. As for needing cling, that's only if you need the dynamic features. It is also possible to use it to generate bindings to be used for cffi. You need to pre-instantiate templates and such, but that's already the case for any other bindings tool. And for that matter, at that level you could use it to generate what you need for SIP, too. Best regards, Wim -- WLavrijsen@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net