[Qgis-developer] Opinion on plugin named prepair (and possible likes)

[Vincent Picavet]

Hello,

Would it be possible in any case to have the boost + CGAL dependencies 
Optional ?
These two libraries are really long to compile, and can therefore slow down 
the development workflow pretty hard.
As for having an internal boost / cgal source tree, there is a strong risk of 
divergence beetween the internal and external versions, and it makes bug 
reporting and identification much more difficult.

QGIS dependencies begins to be really huge, and this complicates a lot 
compilation and deployment.

Is there a chance for prepair to be refactored so that it only use C++/Qt/QGIS 
internals ? What part of Boost/CGAL is used in prepair ?

I like the modular approach much better, just as postgresql "stack builder" 
does. Having an independant prepair executable tool, which is command-line 
driven, can be really interesting for use outside of QGIS. And then it may be 
wrapped inside processing for QGIS integration ?

Keeping everything modular is really important Imho, and should not be driven 
by packaging issue, which can be sorted otherwise.

Vincent


Le vendredi 6 juin 2014 18:54:41, Larry Shaffer a écrit :
> Hi,
> 
> On Fri, Jun 6, 2014 at 10:26 AM, Paolo Cavallini <cavallini at faunalia.it>
> 
> wrote:
> > Il 06/06/2014 18:24, Andrea Peri ha scritto:
> > > SFCGAL is a real hard to compile piece of software. Use it on qgis mean
> > 
> > to
> > 
> > > transformer the qgis in a real hard to compile software .
> > 
> > cgal is packaged in all mayor OSs, AFAIK, so no need to compile it.
> > all the best.
> 
> Not on Mac. But, there is already a formula in Homebrew, and a new one for
> SFCGAL [0,1].
> 
> My concern, Mac-wise, is the Boost dependency. Here are the minimal
> Pros/Cons:
> 
> Pros:
> 
> * Adds prepair, which is awesome for repairing polygons.
> 
> * Adds Boost, which will offer a very robust framework to new devs, who are
> not necessarily adept at Qt developing, for building new core algorithms
> and features.
> 
> * Could *double* the number of devs working on project. For example, PDAL
> and PCL already use Boost, and other 3D/Lidar tools may as well.
> 
> Cons:
> 
> * Boost is a very large compile and install. Since the Mac QGIS.app is
> bundled, the more Boost is used, the more of it needs bundled, possibly
> making the base install of QGIS on Mac balloon to over 1+ GB. Maintaining a
> smaller internal src tree may be a good solution.
> 
> * The more Boost is used within QGIS source (beyond just prepair), then
> there is more new devs have to learn to become accustomed to the codebase,
> i.e. C++, Qt, and also Boost.
> 
> There are probably others; but, adding Boost into the QGIS source mix will
> be a large change, IMHO. I think it would ultimately be beneficial.
> 
> [0]
> https://github.com/Homebrew/homebrew/blob/master/Library/Formula/cgal.rb
> [1]
> https://github.com/Homebrew/homebrew/blob/master/Library/Formula/sfcgal.rb
> 
> Regards,
> 
> Larry
> 
> > --
> > Paolo Cavallini - www.faunalia.eu
> > Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
> > _______________________________________________
> > Qgis-developer mailing list
> > Qgis-developer at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/qgis-developer