[cctbxbb] cctbx debian package: new commit

[Luc Bourhis]

Hi Radostan,

> Let's assume I want to extent the cctbx by 
> adding a module, for let's say absorbtion correction and I want to implement a 
> method called "multiscan" and I want to make a fast python boost extension to integrate 
> with my python code. I need some symbols from any of the shared libs in cctbx.
> How could this be done in Debian or in any other distribution?

First, as I explained earlier, this is an unlikely scenario because chances are that your Python extension needs to use a template class from cctbx, which means you need that libcctbx-dev package providing the source code. Then, unless you want to reverse engineer the compiler options we use, you pretty much need our build system too. So I would dare to say that your use case is too marginal and that anybody interested in developing C++ code based on the cctbx should get the libcctbx-dev package, then setup a directory to integrate in our build system (writing a file libtbx_config and a SConscript at least).

> About the check for version:
> In my patch I did this with SCons[1].
> What this does is to compile and link a test program and check for success.
> I saw in your code that you are doing similar things and we could write some
> simple c++ program that for example includes boost/version and check some
> "BOOST_VERSION"? This way it checks globally for the availability of
> a shared library.

I prefer to do it that way too indeed. For the record, as you have probably noticed, the cctbx uses 3 different ways to do such checks:
1. checks in the Python code of the SConscript files, relying on running e.g. "gcc --version", or parsing some files
2. checks based on #if defined(...) ... #elif defined(...) ... #endif in C++ code
3. the mechanism you describe

Every single new configuration code I personally write uses method 3 exclusively but all other developers mostly use a combination of method 1 and 2. I have got some convincing to do here!

Actually thanks for your remark as I had in mind performing the check at the configure stage and therefore it would be impractical to compile a snippet, leaving me only with the option of method 1. But your remark gave me the idea that I could instead just set an attribute in the build options of libtbx.env and then do all the work at the libtbx.scons stage. 

Best wishes,

Luc