|
|
Geometry : |
Subject: [ggl] Proposal for Delauney triangulation algorithm
From: Simonson, Lucanus J (lucanus.j.simonson)
Date: 2011-10-28 20:20:25
From: ggl-bounces_at_[hidden] [mailto:ggl-bounces_at_[hidden]] On Behalf Of Bruno Lalande
Sent: Thursday, October 27, 2011 3:12 PM
To: Generic Geometry Library Discussion
Subject: Re: [ggl] Proposal for Delauney triangulation algorithm
>Same for platforms. The fact that Boost.Polygon compiles on less platforms than Boost.Geometry doesn't immediately reduce the field of platforms >Boost.Geometry is compatible with as soon as it integrates an adaptation to Boost.Polygon. Again, it's just a tool and by definition a developer who >needs it *is* already running on a Boost.Polygon compatible platform. So the limitation is not implied by the Boost.Geometry adapter.
>
>In general, glue code stuff lives somewhere in-between what it sticks and doesn't imply any dependency and/or field reduction for any of the parts. I >think I pointed this out some time ago on the Boost list when I proposed a Boost.Python function that makes a Python tuple from a Fusion sequence >and was answered I was introducing a dependency between Boost.Python and Boost.Fusion...
This issue is what gets pulled in when someone includes the whole library. Boost.Geometry has the advantage that it has the extensions mechanism. If Boost.Polygon dependency is created in an extension then it is only that extension and not Boost.Geometry in general that bears the added dependency.
I could do something like the gmp override where a dependency can be added optionally by including an additional header file. The "glue" could live in the directory structure of either library, but I think that as an extension of Boost.Geometry would be the most sensible thing from the library user perspective.
Regards,
Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20111028/5186e899/attachment.html
Geometry list run by mateusz at loskot.net