Hi Radi,


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?

E.g.

-if (env_etc.static_libraries): builder = envlm.StaticLibrary
-else:                          builder = envlm.SharedLibrary
+if (env_etc.static_libraries):
+  builder = envlm.StaticLibrary
+else:
+  if hasattr(envlm, 'VersionedSharedLibrary'):
+    builder = envlm.VersionedSharedLibrary
+  else:
+    builder = envlm.SharedLibrary
+

builder = env_etc.get_library_builder(env=envlm)

with the currently repeated code centralized in libtbx/SConscript under

def get_library_builder(env):

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;
http://cctbx.sf.net/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 insert
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
anywhere?

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.

Ralf