Hi Phil,Yes, this is true. I can't see why I should have numpy AND numarray. Because numarry will be the successor of numpy someday, but currently it is not, I choosed to stay with numpy. The only reason to support numpy AND numeric could be to provide a binary module that works either with numpy or with numarray or with none of them. But then, the interface code needs some modifactions. You have to find out in the init function if numpy or numarray or none of both is available. Simply calling import_array() and/or import_libnumarray() does not work. If you call import_libnumarray() when nummarray is not installed you get a Py_FatalError().
Ulrich Berning kindly provided me with code to build PyQwt with configure.py.
One of his changes was to put a few handwritten *.cpp files to interface the Numerical Python extension modules (numpy and numarray) in the qwtmod.sip file.
The problem is that there are conflicts between the header files of numpy and
numarray (numarray should become the successor of numpy, so there is an
overlap in their API). Putting all the interface code in the qwtmod.sip file
leads to compile errors because of the inclusion of the conflicting headers in
the same .cpp file.
Ulli did not see it, because he is only having numpy, I guess.
And at least, if I take a look at Numeric/arrayobject.h and numarray/arrayobject.h, I can see the following:
in Numeric/arrayobject.h: #ifndef Py_ARRAYOBJECT_H #define Py_ARRAYOBJECT_H
in numarray/arrayobject.h:
#ifdef Py_ARRAYOBJECT_H
#error "Can't use numarray Numeric compatability *and* Numeric in same module"
#endif
My recommendation is, either numpy is used, if it is there OR numarray if it is there OR none of them. Using the numpy API AND the numarray API in the same module may work, but was not intended by the Numerical Python Group and seems to be dangerous.
I can think of several solutions to add extra files to a sip module:
(1) put those interface files in a static library that is to be linked to the PyQwt extension module. I think it is a bit tedious and fear that linking a static lib to the extension has a tiny chance of causing problems.
(2) add the extra sources to the .sbf file before it is being used by the Makefile.__init__() function (this is what I did, but it is hackish)
(3) Add an extra argument "extra_sbf = {}' to the Makefile.__init__() function to pass something like: extra_sbf = { 'sources' : 's1.cpp s2.cpp', 'moc_headers': 'm1.h m2.h' }
I prefer (3) and am willing to send a patch. Or do you have another suggestion?
Gerard
_______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
_______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
