[C++-sig] pyplusplus tutorials & GUI wizard

[Roman Yakovenko]

On 1/26/06, Matthias Baas <baas at ira.uka.de> wrote:
> > There are 2 reasons:
> > 1. Filtering. You want to apply different filters on declarations
> > within projects.
>
> Right, so all it requires is a way to specify such a filter, for example:
>
> add_filter(by_location("mypath"))
>
> or
>
> filter_by_location("mypath")

What about custom filter, lets say by class name. For example Qt.Xml module
all public classes starts with QXML or QDom. Here you should to get down to
API.

> > 2. Performance reasons. With pygccxml you can save a lot of time on big projects
> >     by not compiling a source code with GCC-XML every time. On TnFOX project
> >     it saves more then 30 seconds on my computer
> >    ( Windows XP, Pentium 2.4, RAM 1.5G ).
>
> Pyste also has such a feature, so there is already an example that this
> can also be done the "Pyste way".

This is only one possible cache. pygccxml is able to cache declarations too.

> >> Step 1 of the tutorial consists of 12 lines of code where there are only
> >> two things that I really had to specify: the name of the input header
> >> file and a filtering rule (whereas gccxml is on my path, so I didn't
> >> need to specify that in the driver file.
> >
> > You need at least 1 more line import pyplusplus. :-)
>
> Actually, you don't! The config script can run in a prepared namespace
> that already contains everything that is needed. Again, Pyste can serve
> as an example where you also don't have to import anything to use the
> special Pyste commands and classes.

Lets put a side interface files. I will write article that will
explain why I do want to take
pyplusplus to "interface files".


> So far I see no reason why the simplistic interface of Pyste and the
> actual pyplusplus/pygccxml packages couldn't be combined. Actually, it
> would be great if pyplusplus had an interface that would contain the
> Pyste interface as a subset. This would be a big point for attracting
> people who were formerly using Pyste.

I will explain my point later. Also I did not find Pyste users at all.
Try to search using
Google.

> >> (well, maybe the main reason was that I couldn't get it to work with
> >> that SDK I'm currently wrapping).
> >
> > What were the problems? May be I can help you? Or may be you found some bug?
>
> After having another look at it, I noticed the problem. It was just that
> I still had the recursive option set to False when calling
> module_creator.create() and the class that I tried to wrap resides
> inside a namespace, so I take it pyplusplus only saw the namespace but
> didn't inspect the contents of it.
> Now I have an output file that contains some stuff, a lot of stuff
> indeed! Now the question is, how do I reduce this stuff? What filter do
> I have to use? Basically, for now I only want one single class that's
> inside that namespace. So how I can tell pyplusplus to only wrap that
> specific class?

take a look on http://tinyurl.com/9uhv4 or http://tinyurl.com/e44kh.
see filter_declarations method. This should help, if not please speak.

> Another thing I noticed, the header files included in the output file
> are specified with their *absolute* path (even standard header files).
> Is this intentional or is this a bug? I'd recommend to output the header
> names just as they were specified in the original files. Currently, this
> prevents me from taking the generated source files to another system and
>   compile them there.

May be there is some problem with standard header files. But pyplusplus is
flexible enough to allow you to specify additional include directories:

code_creators.module_t has 2 properties:

std_directories
user_defined_directories.

You can add your include directories to user_defined_directories list.

May be this could be done more simple, but if you are an scons user,
than you can maintan single file that will keep all environment variables,
additional include directories for example, in that file and reuse it
from pyplusplus
and scons scripts.

Give it a try an see what will happen.

> - Matthias -

Thanks for your feedbacks.

Roman Yakovenko