search

markov2 / perl5-Geo-Proj4

PROJ.4 cartographic projections library
http://perl.overmeer.net/CPAN
1 stars 3 forks source link

Fails to build with Proj 5.0.0-rc2 #1

Open sebastic opened 6 years ago

sebastic commented 6 years ago

In preparation of the upcoming Proj 5.0.0 release, the libgeo-proj4-perl package was rebuilt with Proj 5.0.0-rc2. Unfortunately it failed to build:

x86_64-linux-gnu-gcc -c  -I./include -I. -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -fdebug-prefix-map=/build/libgeo-proj4-perl-1.09=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2   -DVERSION=\"1.09\" -DXS_VERSION=\"1.09\" -fPIC "-I/usr/lib/x86_64-linux-gnu/perl/5.26/CORE"   Proj4.c
In file included from Proj4.xs:7:0:
/usr/include/projects.h:161:40: error: conflicting types for 'UV'
 typedef struct { double u, v; }        UV;
                                        ^~
In file included from Proj4.xs:2:0:
/usr/lib/x86_64-linux-gnu/perl/5.26/CORE/perl.h:1655:16: note: previous declaration of 'UV' was here
 typedef UVTYPE UV;
                ^~
Makefile:339: recipe for target 'Proj4.o' failed

projects.h is an internal API that Geo::Proj4 shouldn't use, this along with the other old APIs will be removed from the upcoming releases. See the NEWS file details.

markov2 commented 6 years ago

In 2012, project.h became "internal". However, that did not offer all the things I needed. Maybe 5.0.0 has repaired that: I'll have to check.

The new typedef collision is horrible, because I do not have control on either header file. I have to dive into this to see whether there is a work-around. ASAP.

sebastic commented 6 years ago

5.0.0 is not final yet, and the developers are very receptive to feedback. If there is something you need in the new API I'm sure they'll help get it implemented.

Note that PDL has exactly the same issue, so there is quite a bit of demand to make Proj 5.0.0 also work for Perl projects.

markov2 commented 6 years ago

I did not know that PDL had a connection to proj4 as well.

Looking back at the code, my memory tells me that it only has to do with being able to get names defined in the library: struct PJ_LIST pj_get_list_ref() struct PJ_ELLPS pj_get_ellps_ref() struct PJ_UNITS pj_get_units_ref() struct PJ_DATUM pj_get_datums_ref()

Access to these tables is very useful to be able to give some help to the users. For instance, to create option menus in graphical applications. I have no idea whether anyone is using it for real.

I see that PDL::GIS::Proj also does this: my @a = split(/\n/, echo | proj -v $params); to get some info.

It is only a small part of projects.h, so I may also copy that code into my Proj.xs Of course, that needs to be maintained for all libproj4 releases.

Or, not my preference, I could collect that data at compile-time from command-line scripts and insert that in the code.

You may be able to help-out here. rc2 is a bit late to move defs from private to public. -- Regards, MarkOv

drs Mark A.C.J. Overmeer MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net

sebastic commented 6 years ago

Copying the code is probably not a good idea, too maintenance intensive. Although proj releases are not very frequent.

If the changes you need for Geo::Proj4 are too late for Proj 5.0.0, they could be implemented in the next release.

What help do you need from me? My role is mostly as the maintainer of the various Debian packages like proj, libgeo-proj4-perl & pdl.

sebastic commented 6 years ago

I've forwarded your comments to the proj list, see:

http://lists.maptools.org/pipermail/proj/2018-February/007976.html

markov2 commented 6 years ago

Some bad ideas are the only option ;-)

If the changes you need for Geo::Proj4 are too late for Proj 5.0.0, they could be implemented in the next release.

The XS can include proj4 library version dependent parts.

What help do you need from me? My role is mostly as the maintainer of the various Debian packages like proj, libgeo-proj4-perl & pdl.

Forwarding the question to the proj4 mailinglist (and passing back the conclusion of the responses) is really helping. Thanks. -- MarkOv

drs Mark A.C.J. Overmeer MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net

sebastic commented 6 years ago

Reply from Kristian Evers:

In principle we shouldn’t do API changes now, but on the other hand this is the first time the code is properly tested against other libraries so some adjustments can be necessary.

First off, the new API has the following functions:

const PJ_OPERATIONS *proj_list_operations(void);
const PJ_ELLPS *proj_list_ellps(void);
const PJ_UNITS *proj_list_units(void);
const PJ_PRIME_MERIDIANS *proj_list_prime_meridians(void);

Which does the same thing as the pj_get_*_ref() functions you mention. Except that there is no function for getting the list of datums. The reason being that the +datum parameter is “classic” PROJ functionality which will be phased out eventually (we are moving away from the WGS84 hub datum which +datum is based on).

So the simple answer is to use the new API. Unfortunately you will have the same problem since we also have a UV typedef in the new API. So at least I think we should change that in order to not clash with other libraries. Unless there is any objections to this, I will rename the types XY, LP, UV, XXYZ, LPZ, UVZ to PJ_XY, PJ_LP, PJ_UV, PJ_XYZ, PJ_LPZ, PJ_UVZ.

Another solution to the problem would be to move the mentioned functions to proj_api.h. I am reluctant to do that. I want an incentive to move to the new API so the transition happens as fast as possible.

How does that work for you?

markov2 commented 6 years ago

Ok, it's simple to create a proj4 version specific name. I want to stay compatible with a few versions of libproj4.

Except that there is no function for getting the list of datums. The reason being that the +datum parameter is “classic” PROJ functionality which will be phased out eventually (we are moving away from the WGS84 hub datum which +datum is based on).

"we are moving" means future. We are living now. I would like to have a deprecation cycle for this.

I will rename the types XY, LP, UV, XXYZ, LPZ, UVZ to PJ_XY, PJ_LP, PJ_UV, PJ_XYZ, PJ_LPZ, PJ_UVZ.

Excellent. -- Regards, MarkOv

   Mark Overmeer MSc                                MARKOV Solutions

drs Mark A.C.J. Overmeer MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net

markov2 commented 6 years ago

Can you get us on page http://proj4.org/development/bindings.html ? -- MarkOv

   Mark Overmeer MSc                                MARKOV Solutions
   Mark@Overmeer.net                          solutions@overmeer.net

http://Mark.Overmeer.net http://solutions.overmeer.net

kbevers commented 6 years ago

@markov2 I am looking into fixing this. We don't want this release to break anything for current users of the library (except for a few minor details announced in the release notes). This problem has just been overlooked. We are going to break things with the next major version release though.

I suggest you subscribe to the mailing list to keep updated in the future. I expect us to run into several similar issues since we don't get very much feedback from users of the library. Your help in avoiding such problems would be appreciated.

Can you get us on page http://proj4.org/development/bindings.html ?

You are welcome to submit a pull request with the addition.

sebastic commented 6 years ago

The removal of the old APIs in proj is documented in the NEWS file:

DEPRECATIONS

o The projects.h header and the functions related to it is considered deprecated from version 5.0.0 and onwards.

!!!     PROJECTS.H WILL BE REMOVED FROM THE LIBRARY     !!!
!!!                 WITH VERSION 6.0.0                  !!!

[...]

o The proj_api.h header and the functions related to it is consided deprecated from version 5.0.0 and onwards.

!!!     PROJ_API.H WILL BE REMOVED FROM THE LIBRARY     !!!
!!!                 WITH VERSION 7.0.0                  !!!

Keeping support for the proj v4.x releases in Geo::Proj4 for some time makes sense. Support for the new API should be added for users of proj v5.x.

markov2 commented 6 years ago

I am not a user of the library myself, at the moment. I took over maintenance in 2005, because I needed fixes to the original code. But I haven't been using libproj4 myself since 2010, or so.

So many other projects ask for my attention, that I will not get involved on the mailinglist or github here.

On the other hand: on regular basis I have contact with users of my module on CPAN (usually they do not get the lib to compile) As long as there are users, I will try to keep the Perl interface stable. -- Regards, MarkOv

   Mark Overmeer MSc                                MARKOV Solutions
   Mark@Overmeer.net                          solutions@overmeer.net

http://Mark.Overmeer.net http://solutions.overmeer.net

sebastic commented 6 years ago

With the renamed typedef in proj (https://github.com/OSGeo/proj.4/commit/9c75d794177276189d0a2809bc462291e1a070d3) Geo::Proj4 not longer fails to build.

That resolves this issue for the most part. Geo::Proj4 still needs to be updated to use the new API.

sebastic commented 5 years ago

PROJ 6.0.0 has been released and removes projects.h which is used by Geo::Proj4.

proj_api.h is also deprecated in PROJ 6.0.0 and will be removed in PROJ 7.0.0 (scheduled for March 2020).

When using proj_api.h with PROJ 6.0.0 -DACCEPT_USE_OF_DEPRECATED_PROJ_API_H=1 needs to be added to CFLAGS to prevent a compiler error.

Geo::Proj4 should be updated to (also) support the proj.h API.

Using the embedded copy of PROJ 4.8.0 is not desirable.

shawnlaffan commented 5 years ago

The Alien::Proj4 package might be of use here, at least in the short term and for the version 4 bindings. https://github.com/PDLPorters/Alien-Proj4

If the system version of proj4 is >=5 then Alien::Proj4 will build a local version, visible only to the consumers of that package (all thanks to Alien::Build). Alien::Build will use a detected system library by default, so there will be issues where it is built against a system proj v4 and a user later updates to a more recent version. It might therefore be worth trying to enforce a share install by Alien::Proj4.

The PDL issue noted in https://github.com/markov2/perl5-Geo-Proj4/issues/1#issuecomment-364363537 has been addressed in the PDLA fork by using Alien::Proj4.
https://github.com/PDLPorters/pdla-gis

There is also Alien::proj which is on CPAN and does not (yet) lock to a specific version. Github repo is at https://github.com/shawnlaffan/perl-alien-proj4

sebastic commented 5 years ago

Still no progress, eh?

We're going to start the proj transition in Debian soon. That will also trigger the removal of Geo::Proj4 (and its reverse dependencies like Geo::Point) from Debian, as discussed in:

https://rt.cpan.org/Public/Bug/Display.html?id=129222

markov2 commented 5 years ago

Tried to find time to get it done, but did not find enough of it. I need to support all de versions of proj from one module on CPAN, but the libproj do not have that compatibility by themselves.

So: the plan is there, the tasks is complex, the time too limited. I'll report when I have it working. -- MarkOv

drs Mark A.C.J. Overmeer MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net

ppisar commented 5 years ago

You can use https://github.com/markov2/perl5-Geo-Proj4/pull/4 as base for you work. It builds but tests do not pass. I followed only the syntax. Probably it needs more love and understanding to Proj I don't have.

markov2 commented 5 years ago

The issue is that the library has structurally changed completely, from 2D into 4D and such. There is no simple repair.

ppisar commented 5 years ago

In that case keeping Geo-Proj4 for Proj 4 only and forking it for Proj 6, let's say Geo-Proj6, would be more reasonable.

sebastic commented 5 years ago

I suggest to drop the version from the project name like PROJ has done.

markov2 commented 5 years ago

There are many reasons why that is not possible... for one: Geo::Proj is already in use by an other module (accidentally also owned by me ;-)

My current plan is to set Geo::Proj5 and Geo::Proj6 (and Geo::Proj7) next to another, and keep Geo::Proj as the abstract interface, which roles it currently has as well.