yade-dev team mailing list archive

[Janek Kozicki <janek_listy@xxxxx>]

Bruno Chareyre said:     (by the date of Wed, 6 Feb 2019 19:36:19 +0100)

> I see no real interest in splitting since the problems we will face are 
> exactly the same. [...] The price would be more maintainance and
> branch management, thus I'm not a big fan.

I see your point. This makes sense.

We could try including PotentialBlocks by default in the debian
package. And just turn it off in case if any problems arise, just
like we were doing with CGAL before.

If not this, then let's enable it at least in the pipeline, for
website docs.

I didn't touch that stuff yet with the gitlab pipelines, I guess it's
time for me to see what must be changed to make it work. Unless
Vasileios wants to give it a try :)

Enabling FEMxDEM means only adding python-escript to recommended packages.

best regards
Janek


PS: Vasileios, sorry again for missing your important email to yade-dev earlier.


Bruno Chareyre said:     (by the date of Wed, 6 Feb 2019 19:36:19 +0100)

> 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.
> 
> Bruno

-- 
Janek Kozicki