OCCT 7.4.0: BRepAlgoAPI must import BRepBuilderAPI about pythonocc-generator

[rainman110]

Is there are way to hard-code this dependency?

[rainman110]

@tpaviot Fixed this in the generator. Just need a regeneration.

[tpaviot]

@rainman110 I'm not comfortable with this fix. The issue is that the BRepAlgoAPI_Algo class has 2 ancestors, and is skipped by the wrapper. I prefer thinking about a fix related to multiple inheritance.

[rainman110]

Sure... I prefer also a more general solution

[rainman110]

What about this: The main issue wrt to multiple inheritance is to get the "right" order.

From a computer scientist point of view, the dependencies form a directed acyclic graph (DAG). What we need then, is a topological sort of this dag such that a class is defined before it is referenced first.

Instead of sorting on our own, we can use something like this:
https://pypi.org/project/toposort/

[rainman110]

I have made a working proof of concept!

[tpaviot]

@rainman110 Something similar is already implemented in the generator. No "DAG" or "topological sort" but a kind of. It's in the build_inheritance_tree see https://github.com/tpaviot/pythonocc-generator/blob/master/src/generate_wrapper.py#L1212

[rainman110]

I have seen it already! This is limited on single inheritance though, right? I replaced most of this code with toposort and it works really nice.

[tpaviot]

I also have a fix, adding only a few more lines. If we can do the same without any additional dependency, it's better.

[rainman110]

No problem. I found a new problem though in the cppparser itself. It cannot parse correctly the class BOPTools_BoxSelector due to the list in the template arguments.

I opened up an issue at CppHeaderParser:
robotpy/robotpy-cppheaderparser#27

[tpaviot]

opencascade mostly uses single inheritance, only about ten to twenty classes have 2 ancestors.

[tpaviot]

I applied the fix, regenerating the swig files, compilation is building. I'll push when I'm sure everythong compiles

[tpaviot]

interface files were also updated

[tpaviot]

@rainman110 I see the issue you opened on the robotpy/cppheaderparser repository, good point. It's a good news that this package was forked and is maintained by another dev team. Although it suffers from many drawbacks and lacks, it's currently the best tool I found to be used by the pythonocc generator. I started with gccxml 10 years ago, it was more than one hour to parse every occ headers. Now it's only 20s on my machine. That's the most important point : be quick. There are so many generation/compilation necessary when updating to another occ release, that's it's simply undoable without such a fast tool.

[rainman110]

Is fixed by b979afb