[Distutils] changes neccesary to natively support unlimited c++ extensions

[matthes markers]

hi !

recently i experimented with the very bad native c++ support of python &
distutils,
but 'found' a very good library which adds exactly this to python
(distutils).

writing extensions in c is fully supported by the distutils.
not a single error or warning on compilation. very nice!

but compiling and extension-builing of c++ modules is not so extremely easy.
(small probs with library-path, compileroptions, linkeroptions, no special
distutils 'Extension')
boring.

that's why i'd want to propose to include and support the boost python
library
especialy into the python documentation, examples,
and to special support them in distutils.

so people dont have to go and search for their own, and all using
different libs and inventing the wheel twice.

(same thing with py2exe)

proposal:

"""
1) include the boost-python c++ extension library into the distutils to get
the opensource power concentrated on this fine library.  finaly making it the
'standart'.
 
2) add some more power to the build process of the distutils, by 
   automaticaly considering the systems 'include' variable.
   
3) add system independend compile-options to the distutils.
	 +RTTI		-RTTI
	[+Force_C	-Force_C  ]
	[+Force_C++	-Force_C++]
	...
   (because boost needs >extra_compile_args=["/GR"]< and it would be great
to have
    this determinated automaticaly (regex-search for "dynamic_cast" in the
library source).
    this would hit in "extension_class.hpp" for boost)
    
4) most important: document the use of boost in the python documentation, so
writing
   c++ extension becomes the most natural thing one comes in mind to extend
python with.

 
"""


maybe you remember me, some time ago i posted a question, how to extend
python with c++ code.

i got a hint about swig. (greetings to thomas heller!)

so i got myself going and started to explore the possibilities, beginning
with swig.


my findings were basicaly:

swig			(shadowclasses-mode)
cXX			(very limited)
zope-ExtensionClass
boost-ExtensionClass

i compared the tools, and found cxx and swig unusable for large projects.
(containing overloaded operators, templates..)
wxwindows is not using this powerfull extended features, and so swig does a
good job this case. 
dont argue about this.

and yes, wrapping for instance mesa with boost makes no sense. swig is
probably still the best for such tasks. but that's not the point here.

however, i found that the boost-ExtensionClass had the most advanced design,
which simplifies even the reference-counting and operator overloading for
you.


please visit the comparison-page of boost for pro and con of most existing
tools to make writing c++ extensions easy.



1)
the comparison page from boost says it all.

swig and cxx won't do. as we have an interpreted language,
we definitly dont want to use even another intermediate 'compiler'
to get and maintain our extensions.
+ of course everyone is using templates, overloaded operators,
and virtual functions this days. (great features, cant live without them).

zope is great, but boost is basicaly  same, and seems to do more. (still
so?)
it's very easy to incorporate into the c++ code, so it will not
mess up python code in any way (wrappers, shaddow-classes, quirky calling
conventions)
and you need to compile your extension anyway, right?

so i believe, the python community needs a fully supported 'foolproof'
default way for POWERFULL c++ extensions,
which feel like python classes, once imported.

first this means: build of bosst-lib itself should be automated using
distutils "make_boost_lib(path)" which makes the lib, and automaticaly links

it to the extensions build subsequently using boost headers.

(you'll find a better sytax. it's just the idea.)

why? you are right, everyone CAN write this into a setup-script already,
but why was distutils introduced? -> your answer.
i tried, but gave up on compilerswitches. i used the included
msvc workspace to compile boost. uhh..


2)
from doc:

'os.confstr(name)' #Return string-valued system configuration values. 

is documented in os. but works not for windows. (at least for me)

this command (?) is neccessary to implement a systemvariable lookup
for the "include" variable, people use to 'install' librarys.

  system_incl_dirs =  os.confstr("include")
  system_incl_dirs += os.confstr("Include")

extension.py line 98 can become:

  if include_dirs is None: include_dirs=[]
  self.include_dirs = include_dirs + [system_incl_dirs]
  

now it would be easy for me to extend os for confstr,
but i did not found the body of this function (using a overall search)
and dont want to mess up something i just begin to understand
should i implement it?


this change opens the door for python extensions to all 'installed'
librarys (ok, some ideas for the linker?)


3)
noone wants to look up man gcc + msvc + bc5.5 for the exact syntax of a
special compilerswitch. (platform)
people have more important stuff to do.



4)
docs are the key to get features used.
======================================

documentation of boost - python lib is erm.. medium.

i would contribute a rewritten documentation of boost,
and self-made examples. 

not the incomplete buggy examples given in the boost doc,
but compiling and working ones. (using modified distutils + a setup.py)



please tell me your opinion! 

i think of c++ and python as the 2 languages of the future.  (for general
programming tasks)
c++ parts interconnected by python code, which even binds other crap
erm.. code crash-proof (exceptions) to the whole package if realy neccesary.

easily maintainable by changing the script holding high quality, fast,
templated c++ libs and apps together.  python is the dot which makes c++ perfect.

actualy i reorganize my c++ code (mostly commandline) to be controlled from
python (using boost) and give them a gui (wxPython (by dunn, thanks man!)).

this heavily uses:

c++       (+stl+templates+virtual_funcs+operators..)
python    (laaaate binding)
boost     (c++ python interconnection)
wxwindows (best crossplatform gui.)
wxpython  (swig python-binding of the above)
py mods   (ftp, url, regex, ...)
py2exe    (commercial stuff.. need to keep my refrigerator filled by myself
:-(


i think this is a fairly robust design-path.
(thus deserving special support by python + distutils i believe.)

ok, that's all. at least for now :-)


no flames please.

ml

-- 
Sent through GMX FreeMail - http://www.gmx.net