[cctbxbb] Module versioning (was Re: Debian Package)

[Luc Bourhis]

On 4 Sep 2012, at 02:43, Jeffrey Van Voorst wrote:

> On 9/3/12 4:08 PM, Phil Evans wrote:
>> Some of us do link C++ programs to cctbx C++ routines

> Same here...

Ok, sure, my mistake. Holidays are not good ;-) Seriously it begs the question as to why we don't make dynamic libraries on MacOS X. With the modern versions of SCons we use, it is rather trivial and we should remove the hack-ish way we build the boost python dynamic library on MacOS X in the process. But I am digressing here.

So, Radostan, I reckon that the list of shared libraries we would version is as follow:

libcctbx.so                             
libcctbx_sgtbx_asu.so                   
libiotbx_mtz.so                         
libiotbx_pdb.so                         
libmmtbx_masks.so       
libomptbx.so                
libscitbx_boost_python.so
libsimdtbx_memory_allocation_central.so (this one is a work of mine that I will commit soon-ish: just for the record)
libsmtbx_refinement_constraints.so

I have excluded libccp4io.so because your plan is to rely on Debian libraries instead. I have also excluded libscitbx_minpack.so
and libscitbx_slatec.so for the same reason, although I don't know your objectives for those two. I would like to emphasise again, and I am sure all the other cctbx developers will agree with me here, that you have to make sure that, after replacing the libraries we ship by the Debian ones, a significant subset of the Phenix test cases does still pass with flying colours. What is now called t12 should be enough.

Regarding your libtool patch, it appears that for reasons that have nothing to do with my arguments in this thread of discussion,  you have set up env_no_includes_boost_python_ext not to use libtool to version the shlibs. That's how we want it and you should therefore just change the comment explaining the rationales.

However, we are jumping the guns here as this patch will only make sense of cctbx developers are willing to update so-versions as they change the C++ code. Some libraries in the list above are either tiny, or mature enough that the work involve will be trivial (libscitbx_boost_python.so, libsimdtbx_memory_allocation_central.so and libomptbx.so come to mind). On the contrary, libcctbx.so has 70 source files contributing to it and a huge ABI/API.

So, dear cctbx developers, what do you think of versioning those shlibs? Do you think you can commit yourself to update one line in the relevant SConscript after a bunch of changes to the C++ headers or sources (according to the rules laid out by Radostan earlier in this thread)? Again I know that as far as our immediate work (Phenix, Olex 2, etc) is concerned, this is basically useless to us. But having a Debian distribution and easing the adoption of the cctbx by the beam lines at Soleil is worth an effort I reckon. But this is not for me to say alone.

Best wishes,

Luc



 
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://phenix-online.org/pipermail/cctbxbb/attachments/20120904/6f654945/attachment.htm>