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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
