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

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

Hi all,

Le 10/07/2012 18:48, Radostan Riedel a écrit :
> On Tue, 10. Jul 16:26, PICCA Frédéric-Emmanuel wrote:

>>>> if we got a working setup.py all this comes for free ;)

Am I right assuming that:

1) packages, extensions and data files need to be correctly classified
2) only the "install" command need to actually use the standard distutils?

>> ok when overriding the auto_build target we can 
>> step1: build the shared libraries with scons
>> step2 use dh_python2 with setup.py to build all extensions.

not sure about step 2: the extensions are built from many object files,
so we would have to duplicate a large part of the build system.

By the way, scons has some nice introspection features: you can inspect
the dependencies in the build with a command like:

bin/libtbx.scons -n --tree=all,prune lib/cctbx_sgtbx_ext.so | less

>> so if we goes with the setup.py things we need to extract the extension information from their tbx build system.
>> if not, we need to build "byhand" for each version of python supported by Debian like you already did in the rules file.
>> I personnaly prefer the setup.py because this is the standard for python but if this is to much work. Let's build all extensions from their build system.
>> what is your opinion ?
> I'm afraid that this could be too much. They are chaining SConscripts together
> with a lot of targets and checks (with boost threads, with openmp etc.) 
> In my opinion the scons build works good now. We get all extension in ./lib
> and all shlibs in a subdir of ./lib. Seperation of the extension or python
> modules is another problem but you said it's possible so we go that way.
> When I cp all py-ext to cctbx_sources DIR I can easily call the current setup.py
> and I already have a python package. 

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.

The question is now if we should just call
> their scons build system from setup.py or trigger setup.py from SConstruct?
> I personally would prefer a pure setup.py if upstream is on board but we need to 
> build the shlibs too and this works good now with scons and the build of py-ext 
> works also upstream native so it'll be easier to get upstream on board to our changes. 

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.


Reply to: