← Back to team overview

yade-dev team mailing list archive

Re: PotentialBlocks & Particles documentation on website?


On 2/6/19 2:30 PM, Janek Kozicki wrote:

Of course when Vasileios will write a chapter of documentation
in .rst it will be available, but then clicking the references to
relevant classes will not work.

Question is: how do we solve that?
It just needs to turn on that feature either explicitely in pipeline config (cmake .... PB_enabled=ON) or implicitely by changing the default in CmakeLists.txt.

A separate concern, for another discussion is including them into a
debian pacakage release, because it will bring some dependencies with
it. Which might be difficult to deal with, especially given our bad
experience with CGAL. Personally I would prefer that we split yade
into more debian packages, based on their dependencies, like:

yade-cgal-dep,     - parts of yade that depend on CGAL
yade-coinor-dep,   - parts of yade that depend on coinor i.e. PotentialBlocks
yade-escript-dep,  - parts of yade that depend on python-escript, i.e. FEMxDEM
yade-fft-dep       - (future) parts of yade that depend on libfftw (quantum mechanics)
I see no real interest in splitting since the problems we will face are exactly the same. If we know how to package yade-cgal-dep properly then we know how package yadedaily (or any yade-stable) with CGAL. There is no difference. If we don't know how to package yade-cgal-dep, then we must turn the feature off in yade as well. More deb packages would help if there were conflicts such that, e.g., coinor and escript couldn't be installed together. I don't think it is the case here. So the only advantage would be to minimize disk usage for installing the basic yade version, not a real issue. The price would be more maintainance and branch management, thus I'm not a big fan.

In order to build documentation without implying package dependency a solution could be use "#ifdef YADE_POTENTIAL_BLOCKS" more selectively, i.e. make it guard only the parts of implementation which really depends on external dependencies. Then the interface would be compiled regardless of feature activation.


Follow ups