Split geos port for C and C++ API's

[Dave Allured - NOAA Affiliate]

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 <
dave.allured at noaa.gov> 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20210223/999d8666/attachment.htm>