From: Marcelo M. <mm...@ac...> - 2006-03-14 01:02:39
|
Olly Betts wrote: >On Sun, Mar 05, 2006 at 08:50:34PM -0700, Marcelo Matus wrote: > > >>Olly Betts wrote: >> >> >>>The only documentation for it seems to be in CHANGES and as a result >>>it's not so easy to get a coherent overview, >>> >>> >>swig -help also gives you a descriptions of all the available flags as >>well as which one are the turned on by -O. >> >> > >Aha, that's a help (hmm, I just noticed that "swig -python --help" >doesn't do the same as "swig -python -help"...) > >But as a user, it's less than ideal that a number of features seem to >have been documented only in the CHANGES file, not the manual. In some >cases the relevant section can be pretty much read as-is, but in others >a "timeline" of changes needs condensing to describe the final state. > >I'm not meaning to pick on Marcelo's recent work here. I've noticed >this before with some other features and it's working against reaching >SWIG 2.0 if one of the targets is to make sure that the documentation is >complete, as most recently suggested here: > >http://thread.gmane.org/gmane.comp.programming.swig.devel/15884 > > > >>The compiler will tell you if there is a problem with an option and a >>given python version, for example, if you use just: >> >> swig -O ... >> >>with Python 2.1, you will get the following messages at compilation time: >> >>autodoc_wrap.cxx:2468:3: #error "This python version requires to use >>swig with the '-nomodern' option" >>autodoc_wrap.cxx:2471:3: #error "This python version requires to use >>swig with the '-nofastunpack' option" >> >> > >OK, I've been trying out -O and friends. > >It appears that -dirvtable is incompatible with Python 2.1 because it >generates (or at least can generate) calls to PyObject_Call >which Python 2.1 doesn't have. But there's no #error for that one. > > what swig version are you using, there is no PyObject_Call in swig-CVS when using -nomodern... or how are you calling swig? Marcelo >In the case of -dirvtable at least, it should be possible to generate >one SWIG wrapper file which works on both Python versions, since both >versions of the code are present - it just needs a preprocessor check >to only define SWIG_PYTHON_DIRECTOR_VTABLE for Python 2.2 and later. > >Otherwise it seems to work fine for me in testing so far. > > > >>then you just compose the command >> >> swig -O -nomodern -nofastunpack ... >> >> > >That requires me to recheck on every SWIG upgrade if there are any new >options in -O and if so whether they work with Python 2.1, etc and if >not to expand the list of "-noXXX" options. > >It'd be nicer to be able to specify a "minimum python version" for -O >to use to decide which options it enables, which would help prevent this >problem. > >Or perhaps best of all would be to generate both variants of the code >and pick which to use at compile time based on the Python version being >used, but I can see that might be hard to implement. > >Hmm, but that gives me a neat idea - in my own build system I can >generate suitable wrapper files for "Python 2.1" and "Python 2.2 and >later" as I currently do, and then merge them using GNU diff's "--ifdef" >option so I can actually ship a single wrapper file which can >automatically build with whatever python version is available. > > > >>>I don't want to use "-O" only to find a new SWIG release adds to >>>"-O" in a way which breaks my wrappers. I realise that there's probably >>>a small risk, as really safe new optimisations would presumably just >>>default to on, but I guess I'm trying to gauge what the possible scope >>>of "-O" is. >>> >>> >>if you find one of the options to conflict with your code, you always >>can disable the culprit, for example >> >> swig -O -nofastproxy >> >> > >I can, but if I don't detect the problem before making a release this >introduces a regression in my software as far as my users are concerned. > > > >>in the same way with -O1,O2,O3, you need to check if nothing gets broken >>when you use -O. >> >> > >But if "gcc -O3" or "g++ -03" breaks my software, that means either GCC >is buggy, or more likely that my software violates the ISO C or ISO C++ >standard. There's no "ISO SWIG standard" that I can code my ".i" file >to. There's "what's documented in the manual", but that's incomplete in >places. > > > >>>Also, are most of the optimisations Python-only? It looks like -fvirtual >>>applies to other languages, but the others seem to be Python-specific. >>> >>> >>well, -fastdispatch and -fvirtual are 'global', the rest are mainly >>python specific ones. >> >> > >OK, time to test -O with the other languages! > >Cheers, > Olly > > >------------------------------------------------------- >This SF.Net email is sponsored by xPML, a groundbreaking scripting language >that extends applications into web and mobile media. Attend the live webcast >and join the prime developer group breaking into this new coding territory! >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >_______________________________________________ >Swig-devel mailing list >Swi...@li... >https://lists.sourceforge.net/lists/listinfo/swig-devel > > |