[Proj] PROJ 4.8.0, projects.h and projPJ struct

[Judd Taylor]

Using configure assumes you're doing a C/C++ configure build, which is not true in the case of the PDL/Perl bindings, so it's not very helpful. Configure will compile a test program to pull the value. 

That's a lot to ask to build into every build system out there where someone wants to use the proj library.


The PDL binding works by first adding a low level layer that provides access to the library directly. This includes the interrogation of the projections available and the parameters. The next layer up uses a code generator at build time to generate a PDL::Transforms compatible code stub and documentation based on that projection information. So the reason I need the internal projection information is to be used in a code generator that works with PDL. 

Describing how the PDL code generators (called PDL::PP) work, is probably beyond the scope of this exchange. But in general it handles generating C (perlXS/C) code for all of the potential data types/array configurations where the binding could be called. The run time PDL code will select the proper C code for the case in hand. This enables C speed with perl ease of use. There's also lots of built in threading and parallelization optimizations possible. 


Other versioning issues aside, I think this feature should be enabled in the proj_api.h interface. In fact, I think all of the features that the proj binary uses should be enabled through the proj_api.h interface. Especially since "look at the proj source" has been the advice given on this list for so long. Taking care of those uses will likely enable backwards compatibility for all of the existing code out there that uses projects.h.


-Judd

____________________________
Judd Taylor
Software Engineer

Orbital Systems, Ltd.
3807 Carbon Rd.
Irving, TX 75038-3415

judd.t at orbitalsystems.com
(972) 915-3669 x127

________________________________________
From: proj-bounces at lists.maptools.org [proj-bounces at lists.maptools.org] on behalf of Frank Warmerdam [warmerdam at pobox.com]
Sent: Thursday, April 12, 2012 12:32 AM
To: PROJ.4 and general Projections Discussions
Subject: Re: [Proj] PROJ 4.8.0, projects.h and projPJ struct

2012/4/11 José Luis García Pallero <jgpallero at gmail.com>:
> This function sounds good, but I have a couple of objections:
>
> 1. First of all, the portability of old code. The programs that until
> now include projects.h instead proj_api.h should be corrected. I
> propose to rename projects.h to projects_internal.h (for example) and
> create a new projects.h that contains only #include<proj_api.h> Then,
> it can be maintained in programs the #include<projects.h> and it runs
> always: prior to 4.8.0 and 4.8.0 or higher. Previously on this same
> topic I explained that is impossible to check automatically the
> version of PROJ via PJ_VERSION and select the correct header to
> include because if projects.h is included after proj_api.h some errors
> of conflicting types appears. Creating new projects.h could avoid this
> gotcha.

José,

On linux configure can check for projects.h and probe for versions.

On windows you are generally having to handle proj yourself so what
is the big issue about different versions?

I guess I just don't feel this as a serious issue.

> 2. What about the old code that uses explicitly some fields of projPJ
> structs? Why in 4.8.0 projPJ fields are not public? For old code that
> uses explicitly fields of projPJ the solution of the point 1 is not
> valid. Another solution could be to define explicitly the PJ struct in
> proj_api.h. Whith this solution plus the new projects.h I think that
> almost all old code should have not problems with new 4.8.0 version

A large part of the reason for making projects.h private was to break
the dependence of application on the particulars of the layout of the
projPJ structure!  So, if you really need it, just include projects.h and
manually copy that from the source distribution.  But if you want to
follow the public API contract then stick to proj_api.h.

I don't mean to be peevish, but to me this seems to be an issue from
half a decade ago.  I've certainly been advising all to migrate to proj_api.h
for a long time.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Software Developer
_______________________________________________
Proj mailing list
Proj at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj