Re: Bug#679990: ITP: clipper -- object oriented development kit for crystallographic computing
On Thu, 5 Jul 2012 16:25:51 +0200
Radostan Riedel <raybuntu@googlemail.com> wrote:
> On Thu, 05. Jul 16:11, Baptiste Carvello wrote:
> > I'm a little bit lost here, I did not even think that they use libtool.
> I think what Fred meant is that they need to start thinking about versioning
> their libs and libtool is a nice example here.
Yes I point to the .so naming schema used by libtool.
It would be easier for use if we could use autotools for all the C++
library. But at the end if the upstream author do not care about AI/ABI
stability it would be difficult :(
> > That's also my opinion. At least, a static library can be shared with
> > other packages which build-depend on us.
> But then only the python interface would work. Other packages depending on the
> c++ interface wouldn't work. I found this wiki entry[1] where I'm reading:
>
> ""Currently, the only generally accepted use of this feature in Debian is to add
> non-standard library path (like /usr/lib/<package>) to libraries that are only
> intended to be used by the executables or other libraries within the same source
> package.""
>
> So either with rpath nor static linking we can provide libs for objcryst-fox
> with our package
>
Exactly the kind of problem observed with objcryst-fox or other project
we need public libraries so we need thoses .so numbers so the upstream
need to care about thoses numbers at the end.
the starting point indeed is to provide a patch for their scons build
system then teach them about so versionning.
Radostan do you know if the upstream are aware of this verisonning
problem ?
Do you know also why they chose scons (windows, or because they know
about python ?)
what is the frequency of their releases ?
Do we have a list of project relying on cctbx C++ library. we already
know about objcryst-fox -> what else ?
> > It's not that much debtree as it is Graphviz. I made a quick python
> > script to parse the libtbx_config files and generate the graph. I
> > attached the script and the result to the wiki page. Red boxes are
> > python modules, green boxes are others (C++ or external). Black arrows
> > are run-time dependancies, red are build-time, green are optional.
> Great! But I don't see anything on the wiki page yet...
Great script :)
I added the link to the attached png in the page {{attachement:blabla.png}}
now it is visible from the wiki. (very professional :))
I am a little bit concern by the list of libraries which are not int the graph.
Radostand are you sure of the list you gave me ?
example : libsmtbx_refinement_constraints.so
See you
Fred
--
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: