cctbx debian package: new commit

[Luc Bourhis]

On 4 Oct 2012, at 17:11, Radostan Riedel wrote:

> MOVING to Debian-science-maintainers list since I send my answer by mistake to
> cctbxbb.
> 
> On Thu, 04. Oct 10:05, Luc Bourhis wrote:
>> 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).
> OK I'm sorry but I don't really understand why. Maybe I'm lacking some
> c++ knowledge here. Our dev-package provides every header file needed to develop and
> link against cctbx shared libs.

Sure. I just wanted to emphasise that for most the cctbx C++ API, you would need to #include a header but you would not link to any library. 

> I don't see the sense for a developer to integrate into your build system all
> the time. Maybe you just want to make a quick python module with pure distutils
> and just link code againts libcctbx for instance.

I picked randomly one of our test Linux machine (FC13: I tried to check on Debian 6 but I could find how to install python-config):
- python-config tells me that -fwrapv will be used by distutils whereas we don't use it
- on the contrary, we use -fPIC whereas python-config does not show that.
That makes me worried already and it could be worse as there is no reason the divergence does not increase over time. That's what I meant by reverse-engineering our compiler options. Sure that's doable. But I don't think that's a good idea on the long run.

> But again I'm not a c++ developer nor do I understand the complete
> reasons but I believe you when you say it's not necessary to distribute public
> shared libraries. Also I don't want to hold endless discussions, cctbx decided and 
> I'm ok with it.

Ok, thanks for your trust! Now to be perfectly honest, as you probably remember from the discussion on the cctbx mailing list, there are actually people who link against libcctbx.so and libiotbx_pdb.so. Specifically Phil Evans' (in his programs pointless, aimless and scala) and Jeffrey Van Voorst. I wish they did not do that but well… one struggle at a time!

> In this case I'm not comfortable with distributing this libs as private in Debian either.
> I suggest linking the python-ext statically. It can easily be done with an option in 
> libtbx.configure.

You mean --static-libraries? Yes, sure that would create static libraries libcctbx.a, libiotbx_pdb.a, etc that would then be statically linked (quite a misnomer this phrasing since it really means included into) into the Boost Python shared libraries. Actually, if you are interested in building the few pure C++ test programs of ours, you should use --static-exe to do the same static linking for those executables (--static-exe implies --static-libraries as you can expect).

Best wishes,

Luc