#45 GCC 4.7.2 Compatibility

[Alex Leach]

Hi,
I'm trying to use Py++ to help generate wrappers for this C++ library I had started wrapping with Boost. I thought this could save me a LOT of time and as I've only just started learning Boost.Python, figured this could give me a real head start!

Unfortunately, I'm having some problems, I think because gccxml only officially supports the c++98 standard, whereas the library I'm wrapping conforms to the C++11 standard.

Before realising this, I went ahead and wrote a simple command line utility to use Py++, as the headers I am wrapping are installed in a system-wide folder, and the GUI tries to write there, even though my user doesn't have write-permissions.

I attach it for anyone else who'd like a simple command-line interface to PyPlusPlus.

[Alex Leach]

(Sorry, just meant to upload the py++ file then; forgot "Add artifact" meant it would submit the full report)

So far I've just tried wrapping a single header file; just one picked at random from the public API of this library. Perhaps that's part of the problem, as a real program would include loads of other headers too... The following command is returning loads of errors about size_t and some other methods in the standard library.

I'm also having to specify all of the include directories, whereas gcc would find most of them automatically. Should this be the case? For example, a command I've been trying out (fairly self-explanatory I hope):

[code]
py++ \ -I /usr/include/c++/4.7.2 \ /usr/include/c++/4.7.2/tr1 \ /usr/include/c++/4.7.2/x86_64-unknown-linux-gnu \ /usr/include/x86_64-linux-gnu \ /usr/local/include \ -s /usr/local/include/<source-header-file>.hpp \ -o py++-test-output
[/code]

Py++ then prints out the following gccxml command:

[code]
INFO gccxml cmd: /usr/bin/gccxml_cc1plus -I/usr/include/c++/4.7.2 -I/usr/include/c++/4.7.2/tr1 -I/usr/include/c++/4.7.2/x86_64-unknown-linux-gnu -I/usr/local/include -I/usr/include/x86_64-linux-gnu -o py++-test-output.s -I"." "/usr/local/include/<source-file>.hpp" -fxml="/tmp/tmpQH_Cza.xml"
[/code]

I attach the full error output. There's quite a lot. I think I've got all the includes right, but files like limits.h exists in a few locations. I've tried including all of variations of them, but it still produces errors.

Do you have any suggestions for getting this to work?
Cheers,
Alex

[Alex Leach]

Py++ command line interface

[Alex Leach]

PyGCCXML error output with GCC4.7.2, when trying to compile single C++ header from NCBI Blast+ library

[Alex Leach]

Error output was too big to attach (413K > 256K), so I gzip'ed it..

[Jason Kankiewicz]

Have you tried using the latest version of GCC_XML?
The comment on its latest commit reads:

Update GCC 4.8 headers to work with gccxml's GCC 4.2 parser

[Alex Leach]

No, not yet... I've been hand-writing my Boost Python wrappers since then, but I do need to have a look at the gccxml updates, as I did some work on the gccxml build system and could have done with these changes, by the look of them. Thanks for letting me know; I'll check it out when I get a chance

[Alex Leach]

Hi,

Sorry I've taken so long to report back. It is a gccxml problem, and as I needed it to work, I spent quite a lot of time looking into gccxml's source code...

I went so far as to remove the internal GCC 4.2. compiler, and turned gccxml into a GCC plugin, compatible with GCC 4.7+. It doesn't work on Windows, however, essentially due to a lack of interest by GCC core maintainers.

EDIT: The plugin's available at: https://github.com/alexleach/gccxml_plugin

Although I had to make a couple of edits to the pygccxml source code, it seems to work well. I've upgraded the py++ script I attached above, to recursively create Boost Python bindings from a given directory, and ended up with over 2,000 Boost Python source code files, from a subset of a complete library I'd like to use from python. Although I haven't tried compiling or running it, the code looks good, so it seems to work well..

I guess you'll be interested in what patches I needed to implement:-

• Changed the logic in parser.source_reader.source_reader_t.create_xml_file, so that it prints all output from GCC, and doesn't raise an exception when warning messages are printed. A patch is attached.

• There's a missing fundamental type. IIRC: uint128_t. I just hacked a fix, (returned from a function instead of raising an error) I'm afraid, although I saw an example of where someone had submitted a similar set of patches.. I should have time to send patches in a few months, but just don't atm I'm afraid...

I do have a couple of questions, however. I was looking through the generated source files, and noticed that all includes use absolute paths, and every source file includes the umbrella header <boost python.hpp="">.

I was planning on using sed to replace the prefix component (e.g. /usr/include/) from the include paths, but can pyplusplus do that already, given some include paths?

Replacing #include <boost/python.hpp> with separate includes would be a lot more work to implement, I guess, but it'd probably be less work than doing it manually for over 2,000 header files, which was only a subset of a library I'd like to use from Python... That'll take forever to compile!

Again, I don't have the time to look into this now, but I would be willing to look into this in a few months time (ie. after completing my PhD). If you've any thoughts, I'd appreciate suggestions on where in the code to look...

Another couple of places I'd be interested in working on / using sed for:

• Automatically change case convention from whatever it is, to something a bit more PEP7/8-like, for all class, function, method and attribute names exposed to Python. e.g. convert function and method names to snake_case.

• If a method name starts with 'get' or 'Get', use add_property instead of def. If a corresponding setFoo method is declared, use that as well.

• I was planning on using sphinx, sphinx-breathe and doxygen to document the C++ code, and started doing so with manually exposed code. I'd like to automate that process as much as possible... e.g. add a lot of either @sa or @copydoc directives to inline code comments.

I've got to say, I think you've made a great package here! It must have taken a lot of time to get it where it is now! Thanks for sharing!

Kind regards,
Alex