Um, cancel this, it is probably not needed. Public use of the geos C++ API is strongly discouraged by the source. A quick scan on my local system finds no ports that are actually using the C++ API, except indirectly through the C API.
On Sun, Feb 21, 2021 at 1:42 PM Dave Allured - NOAA Affiliate < [email protected]> wrote: > I would like to split the geos port in two, for C and C++ API's. The > purpose is to improve dependency management for the 41 dependents > (currently). In particular I want to reduce the need for many gratuitous > rev bumps on every minor release. > > Upstream GEOS says the C ABI is long-term stable, but the C++ ABI changes > rapidly. They recommend using the more stable C API when possible. They > provides separate header files and binary libraries for C and C++. > However, both API's are combined in the single geos package build. The C > ABI is presented as wrapped around the C++ ABI. > > As a macports novice, I seek advice on the best way to do this. This > seems good: > > * *geos_cpp*: Rename the original port to this. Dependent ports that > actually use the C++ API would be phased into this dependency. Internally, > this port would build both C and C++ ABI's, so the original geos build > system would be used the same way that it is now. > * *geos*: For dependents that use only the C API. This would become a > wrapper port that would depend on geos_cpp, but would not actually build > any code. > > I could also imagine *geos* (for C++) and *geos_c* (for C) ports. Any > thoughts? >
