Here's a little history on the development of the Proj interface that is relevant here.
When I first wrote it, I only use the proj_api.h file, and its functionality since that is all that's mentioned in the Proj official docs (which were a mess themselves at the time). However, after going back and forth with the developers over years, the answer to all of my questions was inevitably "don't worry about using the published API, just look at the code from the proj binary tool". This inevitably leads to including projects.h, and using the internal functions. Despite what the docs say, this is the "normal" method of developing code that uses advanced features of the proj lib. It's also worth nothing that when I was getting this answer (suggesting using "projects.h"), that header was _already_ "deprecated". The specific functionality required for the PDL bindings is the ability to enumerate the possible projections and their parameters, which is used as input to the code generator that uses that information to write the subs for the interface. This functionality was not included in the proj_api.h interface, and may not be now (I haven't needed to work directly with proj since version 4.4.8). This is why the version that does not include projects.h gives me a segfault at build time, since it's used by the code generator. We need to verify if this enumeration is available through the proj_api.h header (and I doubt it). And if not, then we may need to specify installing the proj-devel package (which I'm guessing would include the correct projects.h) as a requirement for building the PDL Proj interface. At a minimum, we could turn of building Proj if projects.h is not found. In my most honest opinion, this problem, like all previous problems with the proj interface comes down to someone using a proj version that is missing something. Given they call project.h "deprecated", when in fact there is no replacement for the functionality, I think they jumped the gun on removing this file from the installed package for 4.8.0. -Judd ____________________________ Judd Taylor Software Engineer Orbital Systems, Ltd. 3807 Carbon Rd. Irving, TX 75038-3415 [email protected]<mailto:[email protected]> (972) 915-3669 x127 ________________________________ From: David Mertens [[email protected]] Sent: Sunday, April 08, 2012 9:18 PM To: Sisyphus Cc: chm; [email protected] Subject: Re: [Perldl] CHM/PDL-2.4.10_002.tar.gz released to CPAN On Sun, Apr 8, 2012 at 7:23 PM, Sisyphus <[email protected]<mailto:[email protected]>> wrote: ----- Original Message ----- From: "chm" <[email protected]<mailto:[email protected]>> To: "Sisyphus" <[email protected]<mailto:[email protected]>> Cc: <[email protected]<mailto:[email protected]>> Sent: Monday, April 09, 2012 1:39 AM Subject: Re: [Perldl] CHM/PDL-2.4.10_002.tar.gz released to CPAN I think a combination of the PDL-2.4.10 version of Proj.pd with the new code for 4.8.0 implemented with appropriate #ifdefs on PROJ4 version should work with old and new proj installs since it would use the current stable implementation for pre-4.8.0 verions of libproj and then the new code for more recent versions. It shouldn't be that complicated and I've yet to *see* any evidence that it is, having invested quite a few hours in trying to find such evidence. In fact, I've yet to *see* any evidence that there is *any* problem with the proj.pd I committed recently. (If someone could actually send me such evidence, that might ease my frustration. Otherwise I'll just have to wait until the cpantesters web server is up and running again.) Cheers, Rob _______________________________________________ Perldl mailing list [email protected]<mailto:[email protected]> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl Hey Rob - Every code contribution is important. I don't use PROJ, but I appreciate *any* work that makes PDL a better tool! However, I'm sure you can understand Chris's frustration here: he needs to be absolutely sure that any changes he makes do not break anything in PDL, yet tests were failing, and he was able to reproduce PROJ test failures on his own machine using old PROJ libraries. Ergo, revert the PROJ changes and re-release. Since Chris is in the middle of some nontrivial internals work, and since Chris is the project maintainer, I think he is justified rolling back to a previous set of bindings so that he can be confident that nothing breaks in his work. But once his work has finished (or at least reached a stable point), we should push forward with your PROJ updates. In the meantime, I doubt you need the memory mapping code, so holding your own PDL back at 2.4.10_001 would probably work out fine. Chris may have been a bit hasty in calling your contribution "broken." Chris is a nice guy and I'm sure it was out of honest frustration. But too much hastiness leads to flared tempers, so let's all take a deep breath, let the "smoke" clear on the memory mapping, and then work on the PROJ bindings. David -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
