Re: Bug#679990: ITP: clipper -- object oriented development kit for crystallographic computing
Hi,
Le 05/07/2012 14:45, Radostan Riedel a écrit :
>> 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].
I'm a little bit lost here, I did not even think that they use libtool.
Also, what I'm mostly worried is the fragile base class problem (C++
still has that, right?) If the soname needs to change whenever the
fields of any class are modified, this won't be easy to automate.
>> 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.
> In my opinion this is not a good idea. I don't want to loose the c++ interface
> And I know some projects which are using the c++ class library. Otherwise I
> could just go and statically link those libraries into the python extensions and
> not deal with rpath.
That's also my opinion. At least, a static library can be shared with
other packages which build-depend on us.
>> 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].
> Good idea!
>>
>> 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.
>>
> debtree looks nice I'll look into it.
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.
Cheers,
Baptiste
Reply to: