[Proj] PROJ 5.0.0RC2

[Kristian Evers]

My ideas was to only rename the datatypes in proj.h, so not breaking backwards compatibility. I am quickly realising that it is
not so simple as I thought. I am sure it is possible and I think it is worth the hassle to make sure we don’t clash with other
libraries in the future.

One change I believe we can do to fix the immediate problem is to remove the following two lines from projects.h (line 161-162): 

typedef struct { double u, v; }        UV;
typedef struct { double u, v, w; }     UVW;

The build completes and UV/UVW doesn’t get in the way of anything else. Have I overlooked something that hinders this idea?

/Kristian

> On 9 Feb 2018, at 13:17, Thomas Knudsen <knudsen.thomas at gmail.com> wrote:
> 
> > The typedef was introduced in projects.h in proj 5.0.0-rc1. 
> 
> It has actually been part of PROJ forever. For a number of releases, however, it has been deffed away as, iirc, projUV: Part of a hack for making all of XY, LP and UV look alike (I have never understood why it was necessary, and it broke the classic PROJ pj_init/pj_fwd/pj_inv/pj_free API).
> 
> It took major code surgery to step between all the tripwires the projNN deffing had created, so be careful when touching it, and note that renaming datatypes will break backward compatibility for everyone.
> UV was hardly ever used, so perhaps it is way easier to just rename UV, which is mostly a PROJ internal type.
> 
> This would also open an opportunity to consider eliminating the projection approximation subsystem (gen_cheb.c, mk_cheby.c, biveval.c etc.) - a nice milestone for release 6 or 7 :-)
> 
> /thomas
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20180209/4c1a9382/attachment.htm