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

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

On Tue, 10. Jul 16:26, PICCA Frédéric-Emmanuel wrote:
> > > if we got a working setup.py all this comes for free ;)
> > You're right but I need to call their scons system to build the extensions and
> > shlibs.
> 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.
> 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. 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. 

But it's only my opinion if you say it's better then I'll follow your lead :)


Reply to: