> > I spent dozains (hundreds?) of hours playing with SWIG/pygccxml/OCC > headers/compiling/testing etc. This is my advice for an efficient work: > > STEP 1: > - the first thing to do is to work *manually* on the SWIG files (.i). > Choose only a few basic modules (for instance Standard, gp, Geom) ; > - this 'manual' hack allows easy experimenting on new features (easy > because the compilation time is small). You will notice strange behaviors. > The C++ file generated by SWIG has to be deeply studied and understood; > is there a simple way to compile a single module or a selected few? or you write the compiler command manually at this stage.
> - when you have manually introduced a new feature (for instance class > renaming, or Handle_ removal) and checked that it work as expected, create a > unittest ; > > STEP 2: > - *only then* you can start trying to generalize this new feature to the > whole wrapper, using pygccxml. SWIG_generator.py is just a script that > automates something you manually tested and validated; > - you will have to check that all modules still compile (it's *never* the > case), why they don't (you'll have to add many 'if .. then..' in the > generator to handle specific cases or exclude some classes/methods that make > the compilation fail), and finally check the feature for other > classes/methods. > - check that you didn't introduce any regression (run the full unittest > suite) > - check that this new feature works for both Linux/MacOS/Windows platforms > (Windows compiler is MSVC). > In brief, there are a lot of constraints that can make a simple and good > initial idea become a real nightmare (believe me!). > I believe you, thanks for the guidlines. > > I agree my SWIG_generator.py is messy and almost unrefactorable. It's full > of 'if ... then..' statements that were added while I was introducing new > features. I found the files you sent me in april 2010, and the structure of > your draft is much more simple and clear than mine. However, the automation > of the SWIG generation files is not an issue. > I commited the most recent code i have to the wrapper_refactoring branch, for reference and to fish out some useful bits of code as we go. agree that there is no need for refactoring, this was mostly for me to understand better what the swig generator actually does. > > So, at first, I really do want to work with you on such improvements of the > wrapper. A good plan would be to : > - choose *one* new feature to implement ; > - follow the workflow I previously defined ; > > Let's create another development branch, with the SWIG files in their > current state from the svn trunk, my SWIG_generator, and your files. > Shall we start with the handles then? 1. Rewrite all arguments starting with Handle_ 2. Add convertion code from Object to Handle for the arguments 3. Rewrite all function signature returning a Handle 4. Convert Handles to Objects before returning. 5. Remove All handle classes in the wrapper files Had a look at the code in the wrapper_refactoring branch, found some code that looks like its rewriting methods signatures that accepts Handle_* const & as argument (SWIG_generator.py around line 385) but couldnt find any code that seems to do any rewriting. Wouldn't it be possible to generate in and out %typemaps for every Handle type or do you know of a more efficient solution? Henrik
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
