cctbx debian package: new commit

[Luc Bourhis]

Hi Frederic,

> Now we are waiting for a feedback of luc on the current patch series of the packaging. we agreed with Luc to put a summary of the status of each patch into the wiki.
> thaht way it will be possible to coordinate on the wiki.
> One we got this feedback it will be possible to rework this patch series and integrate as much as possible of thoses patch inot the upstream code.

I apologise for not having done it yet. I will update the wiki this week.

Now onto the meeting we had in Cambridge after the Phenix workshop. Nat was adamant to use upstream CCP4 instead of the patched version we currently rely on and he and Marcin started to look at how and when to push the Phenix patches upstream. So good news on that front.

Onto another subject altogether, we have also decided to add a new option to libtbx/configure.py to automatically check whether the external dependencies are installed and with the right version and if not to warn the user and then install them: --update-external-dependencies=(no|ask|yes). We basically had enough of the bug reports boiling down to the wrong version  of Boost (and a few years ago it used to be SCons) and it will get worse when the CCP4 will be another external dependency. The default will be yes, so that's one thing to keep in mind when you will build the Debian port. This new feature is not coded yet but it should be done within a month.

Finally, the thorny subject: shlibs versioning. The reaction was lukewarm to be honest.

The key problem is that everybody felt that those shlibs are just an implementation detail of the cctbx,  to avoid recompiling the same code. For example, libiotbx_pdb.so is linked into the Boost Python extension iotbx_pdb_ext.so that is to be used from Python script and the pure C++ program Phaser as a trick to avoid recompiling all the iotbx/pdb/*.cpp files. We see it as a trick because it does not work in the large: most of the cctbx C++ code heavily uses template functions and classes and it is therefore header-only. A C++ developer must and only need to include the relevant headers in his code. The implementation-detail aspect is nicely illustrated if we were to make one key class of e.g eltbx into a template: this could result in pulling all eltbx/*.cpp from libcctbx.so.

So basically, we are not kin on promoting the use of those shared libraries. Thus is there a way to declare shared libraries as private to a port in Debian? 

Best wishes,

Luc