Can anyone name a reason why the MK core makefile should continue to include autoconf & libtool logic for building the Python extension (shared or static)?
With Distutils being the standard way to build things in Pythonia nowadays, and since MK now has a python/setup.py script, I'm tempted to throw Mk4py out of the makefile. Finding the proper /usr/include/PythonX.Y/ directory has always been tricky anyway.
I've not checked how setup.py actually builds and whether it includes things like -fPIC when compiling for linkage into a shared library. Nor whether Distutils is mature enough now to work with MSVC, mingw, and more esoteric platforms / compilers / C++ runtimes.
You can check what machines you are running on and change compiler settings in the setup.py
I deploy my chemoinformatics system using setup.py and extension creation that targets g++ on unix/linux and Mac and msvc or cygwin g++ on windows. Additionally, I believe there are targets for codewarrior and I don't think that mingw would be that difficult as well.
I agree that mk4py should not be in the Makefile, since setup.py should be able to get the appopriate headers and build for the current version of python (2.2, 2.3 etc) altering the Makefile for this is a bit of a pain.
Not sure about Mk4py cross-compilation either, nor whether it matters.
I do know that "python setup.py build" is a lot simpler than configure/make when the proper ./configure --please-make=my/build:work/right incantations are not known or understood well enough...
-jcw
_______________________________________________ metakit mailing list - [EMAIL PROTECTED] http://www.equi4.com/mailman/listinfo/metakit
_______________________________________________ metakit mailing list - [EMAIL PROTECTED] http://www.equi4.com/mailman/listinfo/metakit
