<div dir="ltr"><div>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. </div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 21, 2021 at 1:42 PM Dave Allured - NOAA Affiliate <<a href="mailto:dave.allured@noaa.gov">dave.allured@noaa.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">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.<div><br></div>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.</div><div dir="ltr"><br><div>As a macports novice, I seek advice on the best way to do this.  This seems good:</div><div><br></div><div>* <b>geos_cpp</b>:  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.</div><div>* <b>geos</b>:  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.</div><div><br></div><div>I could also imagine <b>geos</b> (for C++) and <b>geos_c</b> (for C) ports.  Any thoughts?</div></div></div>
</blockquote></div></div>