Re: RE : Bug#679990: ITP: clipper -- object oriented development kit for crystallographic computing
> I was also wondering about the C++ interface. While static libraries
> waste disk space, they could be provided in a -devel package without
> having to commit to ABI compatibility (if I understand Policy 8.3 well).
>
> On the other hand, with a real lib package, we would have to maintain
> the SONAMEs. If, as I fear, upstream won't help with this task, and this
> beeing C++, I'm afraid it could be a difficult task.
>
For ABI Compatibility we need to talk with the upstream again. My idea for now
is to make the soname versioning work with scons. That way they probably don't
need to change much on their build system but it'll be clearer for us to pack.
Problem with cctbx will be that we need a build system that builds our libs
first and uses them then to compile the python modules but we also need some
kind of method to make proper python packages. Thats why I started to write a
setup.py file which imho is the best way to go here. In my last talk with the
upstream they where open for an alternative distutils build process.
But we need to figure out an easy way to submit a patch to upstream which will
as delicate as possible modify their build process so they have no argument in
rejecting our changes.
> Personnally, I always used cctbx in homegrown scripts (mostly sgtbx and
> uctbx). For that kind of use, a big package is fine IMHO, as you don't
> want to spend time cherry-picking the parts you need.
But we don't want to use scripts or ENV variables ;). My thinking was just that
maybe the whole package is not always needed. I have a small django project at
work which just needs the cctbx interface. No need for mmtbx etc.
Maybe I could make a small python script to parse that libtbx_config file so we
can automatically create this dependencies like some kind of debhelper scripts
do?
regards
Reply to: