Fails to build with Proj 5.0.0-rc2 #1
Comments
|
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. |
|
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. |
|
* Bas Couwenberg ([email protected]) [180209 06:18]:
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.
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
[email protected] [email protected]
http://Mark.Overmeer.net http://solutions.overmeer.net
|
|
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. |
|
I've forwarded your comments to the proj list, see: http://lists.maptools.org/pipermail/proj/2018-February/007976.html |
|
* Bas Couwenberg ([email protected]) [180209 09:15]:
Copying the code is probably not a good idea, too maintenance
intensive. Although proj releases are not very frequent.
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
[email protected] [email protected]
http://Mark.Overmeer.net http://solutions.overmeer.net
|
|
|
* Bas Couwenberg ([email protected]) [180209 10:59]:
> 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);
> ```
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
[email protected] [email protected]
http://Mark.Overmeer.net http://solutions.overmeer.net
|
|
* Bas Couwenberg ([email protected]) [180209 06:18]:
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.
Can you get us on page http://proj4.org/development/bindings.html ?
--
MarkOv
…------------------------------------------------------------------------
Mark Overmeer MSc MARKOV Solutions
[email protected] [email protected]
http://Mark.Overmeer.net http://solutions.overmeer.net
|
|
@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.
You are welcome to submit a pull request with the addition. |
|
The removal of the old APIs in proj is documented in the NEWS file:
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. |
|
* Kristian Evers ([email protected]) [180209 11:56]:
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.
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
[email protected] [email protected]
http://Mark.Overmeer.net http://solutions.overmeer.net
|
|
With the renamed typedef in proj (OSGeo/PROJ@9c75d79) 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. |
|
PROJ 6.0.0 has been released and removes
When using Geo::Proj4 should be updated to (also) support the Using the embedded copy of PROJ 4.8.0 is not desirable. |
|
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 #1 (comment) has been addressed in the PDLA fork by using Alien::Proj4. 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 |
|
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: |
|
* Bas Couwenberg ([email protected]) [190712 07:21]:
Still no progress, eh?
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
[email protected] [email protected]
http://Mark.Overmeer.net http://solutions.overmeer.net
|
Proj 6.2.0 depreacted some API and removed some (retrieving a list of datums). This patch aims to make the XS code buildable with 6.2.0 as well as with the previous Proj versions. The unaviable API is solved by returning an empty list. The code builds fine but some tests fail. Probably pj_fwd() changed not only syntax (argument types), but also semantics. I have no idea what proj did or should do. Any advice is welcome. <markov2#1>
Proj 6.2.0 depreacted some API and removed some (retrieving a list of datums). This patch aims to make the XS code buildable with 6.2.0 as well as with the previous Proj versions. The unaviable API is solved by returning an empty list. The code builds fine but some tests fail. Probably pj_fwd() changed not only syntax (argument types), but also semantics. I have no idea what proj did or should do. Any advice is welcome. <markov2#1> <markov2#3>
|
You can use #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. |
|
The issue is that the library has structurally changed completely, from 2D into 4D and such. There is no simple repair. |
|
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. |
|
I suggest to drop the version from the project name like PROJ has done. |
|
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. |
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:
projects.his 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.The text was updated successfully, but these errors were encountered: