Split geos port for C and C++ API's
Dave Allured - NOAA Affiliate
dave.allured at noaa.gov
Tue Feb 23 21:27:17 UTC 2021
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the macports-dev