Re: RE : Bug#679990: ITP: clipper -- object oriented development kit for crystallographic computing
> This scons things is a pain, how many libraries are generated from the cctbx package ?
> can you describe the organisation of the package by providing your expected control file.
> so we can have a better vision of the organisation of the core.
> It is quite obscute me looking at the upstream source organisation.
When I build it with the install csh script they provide it builds these libs.
libmmtbx_masks.so
libscitbx_boost_python.so
libsmtbx_refinement_constraints.so
libboost_python.so
libcctbx_sgtbx_asu.so
libiotbx_mtz.so
libomptbx.so
libscitbx_minpack.so
libspotfinder.so
libcctbx.so
libiotbx_pdb.so
librstbx.so
libscitbx_slatec.so
And of course if also builds a lot of libs that are already in Debian like libboost-python
and there's no other way to get rid of those but patch the Scons scripts
otherwise the python modules *_ext.so get linked against their versions of
libboost etc. And I don't wanna link these modules statically, waste disk space
and loose the c++ compatibility.
About that control file: I'm still not sure how many python packages to build.
Maybe I could get some suggestions here. Since cctbx consists of a lot of python
modules for example smtbx, cctbx, mmtbx etc. which do not depend on each other,
maybe it would be best to split that a little bit up. What is the logical choice
here? Every module has a file called libtbx_config which describes what
dependencies it has.
Example cctbx module:
{
"modules_required_for_use": ["scitbx"],
"modules_required_for_build": ["chiltbx"],
"exclude_from_binary_bundle": [
r"^reference/henke/",
r"^reference/sasaki/"],
}
But I don't know how to make it work with one setup.py yet?
regards
Radi
>
> thanks
>
> Frederic
Reply to: