[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RE : RE : RE : RE : RE : cctbx debian package

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.


Reply to: