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
--
wlavrij...@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
