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

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

Le 12/07/2012 15:56, Radostan Riedel a écrit :
> 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 misspoke: it looks like dh_python2 doesn't use the metadata in
setup.py, but classifies files based on the file extension. Then we
would not need a setup.py at all. Frédéric, what's your take on this?

>> 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

Well, this is a rather big project, not packaged in Debian and dead
upstream. Also, step 1.5a doesn't seem too difficult after all. For now
I implemented a very crude solution that only does the copying of the
extensions, and only for the cctbx package, but calling scons in an
external process should not be too difficult. Especially if I can rely
on the build directory to be already configured.

I work in a git branch I called setuppy which is directly based on the
upstream snapshot. For now, I uploaded it to a clone on bitbucket:

I still have much work to do on it, but you can have a look if you want.


Reply to: