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