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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Karan Sheth via macports-dev
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?
Reply | Threaded
Open this post in threaded view
|

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

Karan Sheth via macports-dev
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 <[hidden email]> 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?