[PROJ] Motion: Adopt RFC3 - Dependency management

Kristian Evers kreve at sdfe.dk
Wed Jan 16 10:11:12 PST 2019


Yes, I agree that we should stay on the conservative side with regards to the API. How about we set up tests on travis and appveyor that checks that the API can be used in a strictly C89 application? Perhaps also a similar thing for the C++ API.

/Kristian

On 16 Jan 2019, at 18:05, Thomas Knudsen <knudsen.thomas at gmail.com<mailto:knudsen.thomas at gmail.com>> wrote:

Thanks, Even, for elaborating on all the stuff I thought and meant, but didn't mention. It was exactly my main concern, that the interface should probably be kept C89(C90)-compatible for quite a while. The library-internal code, since compiled as C++, can wiggle a lot more. All in all going C++11 is a huge improvement, as long as we can keep the C ABI/API reasonably stable/accessible from C and from projects expecting a C ABI.

RFC3 is perfectly fine as is, but proj.h and the ABI and API it exposes needs special care. With that in mind, it is as Kristian indicates: A lot of C99 considerations are more or less irrelevant now that we compile everything as C++11.


Den ons. 16. jan. 2019 kl. 17.08 skrev Even Rouault <even.rouault at spatialys.com<mailto:even.rouault at spatialys.com>>:
On mercredi 16 janvier 2019 15:53:34 CET Kristian Evers wrote:
> Most of the code is now compiled as C++ so probably not a big issue in
> practical terms.

Yes and no. My point was that, in the current state of PROJ master, people can
for example use a separately compiled PROJ with whatever "modern" compiler we
require (or use a PROJ binary from their prefered packaging), but still
wanting to use the PROJ C API with their own build constraints, like enforcing
-std=c89 in their code base, and thus including proj.h with non-C89 features
would break that.

> Just to be clear, I have no intention of updating the RFC as it is now. I
> don’t think the concerns raised here are incompatible with the content of
> RFC3.

RFC3 is fine for me as a general strategy. This is just a example of practical
concrete decisions.
I've sticked to using int in the new C API I've added in cases where bool
might have been used.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com<http://www.spatialys.com/>
_______________________________________________
PROJ mailing list
PROJ at lists.osgeo.org<mailto:PROJ at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/proj

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20190116/e8068ff6/attachment.html>


More information about the PROJ mailing list