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.
Cheers,
Baptiste
Reply to: