On Thu, 12. Jul 09:51, Baptiste Carvello wrote: > Beware: this setup.py does not correctly classify the extensions. I > think they would be treated as package data, which would prevent > dh_python2 from moving them to the right place. I never tried dh_python2 before but dh_pysupport worked good with that setup.py so I'm assuming dh_python2 won't be worse. But I'll try that out.
> I think like Radi: duplicating the build system is not just a one-time > cost, but a long term maintenance cost. Plus it would probably annoy the > upstream developers. > > I'd rather propose another solution: > > step1: build the shared libraries with scons > > _either_ step1.5a: build the extensions with a custom setup.py "build" > command that calls scons under the hood > > _or_ step1.5b: build the extensions with scons and copy the results to > the correct distutils build directory > > step2: use dh_python2 with "setup.py install" to install the extensions > at the right place > > Both step1.5a and step1.5b have their problems (1.5a implies digging > into distutils internals, 1.5b might be a little bit brittle), but I > think that's the best strategy. If nobody objects, I will experiment > with this until the begining of next week and report back if it works. Why do we have to trigger a custom setup.py to build the extensions? Have you seen this[1]. Looks familiar to your idea. [1]http://projects.scipy.org/numpy/wiki/NumpyScons -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
