[cctbxbb] CCTBX for Debian + PATCH
rwgrosse-kunstleve at lbl.gov
Sun Jun 12 16:21:43 PDT 2011
> 1.) The SONAME and SOVERSION is missing from the shared libraries. I'm
> attaching a patch that can fix this for GNU/Linux. That produces files
> like this:
Could you re-do the patch to reduce repetitive code?
-if (env_etc.static_libraries): builder = envlm.StaticLibrary
-else: builder = envlm.SharedLibrary
+ builder = envlm.StaticLibrary
+ if hasattr(envlm, 'VersionedSharedLibrary'):
+ builder = envlm.VersionedSharedLibrary
+ builder = envlm.SharedLibrary
builder = env_etc.get_library_builder(env=envlm)
with the currently repeated code centralized in libtbx/SConscript under
If you send me your sourceforge user name I'll enable svn write permission
for you, so that you can check in the patch directly.
> 2.) PyCifRW: I had to remove it from the sources because it ain't free
> software because of some lines in their license. It wasn't accepted to
> Fedora because of that, so I guess I can forget Debian either.
We don't depend on PyCifRW anymore. Instead we are now using iotbx.cif;
> 3.) In your changelog I read you wanna get rid of the "from __future__
> import division" and change to "python -Qnew". This would be a problem
> for me, because than I couldn't use it from sys.path anymore. I have a
> Django project at work that imports some cctbx modules directly from
> pythonpath. And I can't really call "cctbx.python" for that, otherwise I
> would have to patch my Apache and mod_wsgi, respectively cctbx.
When you copy .py files into the /usr directories, could you automatically
from __future__ import division
as the first line of all .py files?
> Wouldn't it be better to install all python modules to the standard
> python location of the Distribution than making dispatchers with
> hardcoded paths?
I think Luc Bourhis is trying to work out support for relative paths.
> Also, when the libraries, headers and python stuff
> would be in their standard location, everyone could just import it from
This question has been asked several times before. It would indeed be good
to have optional support for something that works like "python setup.py
install". I'm not sure what's the best way to implement this. Maybe start
with the scripts that you have already? Would it make sense to check them in
under an new directory? (Note that we already have rpmbuild at the top
level; does this help in any way?)
The libtbx/configure framework is designed to avoid copies of Python
sources. If you run "python setup.py install" copies are made. This is
extremely confusing in development. I.e. we really need to keep the
libtbx/configure framework, but it would be good to also have scripts that
copy into the /usr directories for needs like yours.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cctbxbb