Re: Bug#679990: ITP: clipper -- object oriented development kit for crystallographic computing
On Thu, 5 Jul 2012 10:55:24 +0200
Radostan Riedel <raybuntu@googlemail.com> wrote:
> > 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.
if the ABI is not stable we need to be sure that the upstream take
care of the so name changed which come with ABI breakage. they need to
read this [2].
if this is not the case, we can leave with private shared library.
/usr/lib/cctbx look at here [1]. You can also google for debian rpath.
if thoses shared library are only private.
which part of the API is used by objcryst-foc. -> need to provide
libxxx and libxxx-dev packages.
so you are right a few of the library need to be public and we need
this so numbering in their scons build system. this page gives plenty
of scons recipes [3].
> 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.
definitively a setup.py is the right things to do we will use
dh_python2 to build the python modules.
>
> > 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 ;).
yes ENV variables are evils.
> 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?
An option is to create a target in the rule file which generate the
control file from the _config file as you propose, but this target
should be called manualy so it can be double check the same idea was
proposed here [4].
it mean thaht we should propose python-xxx modules for each modules.
maybe debtree[5] can help you and provide a nice picture of the
packaging of cctbx and all its dependencies.
>
> regards
>
>
[1] http://lists.debian.org/debian-devel/2002/07/msg02030.html
[2] http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
[3] http://www.scons.org/wiki/SconsRecipes
[4] http://us.generation-nt.com/answer/bug-357023-pyspf-debian-control-generated-during-build-clean-help-166422011.html
[5] http://collab-maint.alioth.debian.org/debtree/
--
GPG public key 4096R/4696E015 2011-02-14
fingerprint = E92E 7E6E 9E9D A6B1 AA31 39DC 5632 906F 4696 E015
uid Picca Frédéric-Emmanuel <picca@synchrotron-soleil.fr>
GPG public key 1024D/A59B1171 2009-08-11
fingerprint = 1688 A3D6 F0BD E4DF 2E6B 06AA B6A9 BA6A A59B 1171
uid Picca Frédéric-Emmanuel <picca@debian.org>
Reply to: