Dear PDL devs, See new version of the Proj4 code on https://github.com/PDLPorters/pdl/pull/91 - branch projfixp2
It works on my Win32 box when I configure my perldl.conf correctly, and as you can see by the green lights on Travis, it works on Linux too. I will only merge it after it has been reviewed AND worked on Rob and Derek's setups. To answer the question "why is Inline involved", Alien::Proj4 encapsulates the code that P::T::P was relying on P::G::P for, to break that build-time dependency. It uses Inline because it needs to use XS, and since it's in inc/ and not an installable module, that's the only way to use XS. Once Alien::Proj4 becomes a separate installable module, and uses Alien::Base, then a lot of cool stuff will be possible "for free". Best regards, Ed -----Original Message----- From: sisyph...@optusnet.com.au Sent: Tuesday, March 24, 2015 11:39 PM To: Derek Lamb Cc: pdl-devel@lists.sourceforge.net Subject: Re: [Pdl-devel] Proj presently broken -----Original Message----- From: Derek Lamb Sent: Wednesday, March 25, 2015 7:03 AM To: sisyph...@optusnet.com.au Cc: pdl-devel@lists.sourceforge.net Subject: Re: [Pdl-devel] Proj presently broken Hi Derek, > Two items of note from the 4.9.0/4.9.1 Proj4 release notes > (http://svn.osgeo.org/metacrs/proj/trunk/proj/NEWS) > 1) "Install projects.h again for applications that want access to internal > structures and functions despite the inherent fragility." > 2) "Implement new virtual file api (projFileAPI) so that all access to > grid shift and init files can be hooked." > > #1 means that only Proj4 4.8.0 needs the projects.h file included with > PDL. As long as the PROJ_INC location comes *before* the "-I/Users/derek/Build/PDL/Lib/Transform/Proj4/../../GIS/Proj/include" then I *think* this consideration gets taken care of appropriately. >#2 causes a type mismatch error during compilation and aborts make. PDL's >projects.h & Proj4's proj_api.h both define pj_open_lib: I don't think this has bitten me yet - I'm also using proj-4.9.1. > "/opt/local/bin/perl5.16" > /opt/local/lib/perl5/5.16.3/ExtUtils/xsubpp" -typemap > "/opt/local/lib/perl5/5.16.3/ExtUtils/typemap" Proj4_e243.xs > > Proj4_e243.xsc && mv Proj4_e243.xsc Proj4_e243.c > /usr/bin/clang -c -I"/Users/derek/Build/PDL/Lib/Transform/Proj4" > "-I/Users/derek/Build/PDL/Lib/Transform/Proj4/../../GIS/Proj/include" -pipe > -Os -fno-common -DPERL_DARWIN -I/opt/local/include -fno-strict-aliasing > -fstack-protector > -I/opt/local/include -O3 -DVERSION=\"0.00\" -DXS_VERSION=\"0.00\" > "-I/opt/local/lib/perl5/5.16.3/darwin-thread-multi-2level/CORE" > Proj4_e243.c > In file included from Proj4_e243.xs:5: > /Users/derek/Build/PDL/Lib/Transform/Proj4/../../GIS/Proj/include/projects.h:386:7: > error: conflicting types for 'pj_open_lib' > FILE *pj_open_lib(projCtx, char *, char *); > ^ > /opt/local/include/proj_api.h:146:8: note: previous declaration is here > PAFile pj_open_lib(projCtx, const char *, const char *); > ^ > 1 error generated. > FWIW, I'm currently using this patch to inc/Alien/Proj4.pm: ###################################### --- Proj4.pm_orig 2015-03-25 09:53:03 +1100 +++ Proj4.pm 2015-03-25 10:05:16 +1100 @@ -4,6 +4,7 @@ use warnings; use Config; use Devel::CheckLib; +use PDL::Config; my $transform_proj4_lib_path; my $include_path; @@ -19,11 +20,13 @@ '/usr/lib', '/usr/local/lib', '/lib', + @{$PDL::Config{PROJ_LIBS}}, split(/ /, $Config{libpth}), ); my @DEFAULT_INC = ( '/usr/include', '/usr/local/include', + @{$PDL::Config{PROJ_INC}}, $Config{usrinc}, ); my @lib_locations = @DEFAULT_LIB; ###################################### It seems to be doing the trick for me - though I'm still puzzled as to why Inline is getting involved here. > I THINK that all of this could be avoided if it weren't mucking about in > Alien; like Rob, I'm not really sure why the build is spending any there > since sufficient parameters to compile Proj were passed in perldl.conf. I actually don't like Alien at all - it's just a lot of pain for no gain AFAICT. But if people want to implement it, then so be it. That it's causing me problems just strengthens my dislike of it. (An unfortunate consequence of my nasty and vindictive nature ;-) Cheers, Rob > On Mar 23, 2015, at 7:34 AM, sisyph...@optusnet.com.au wrote: > > Hi, > > Trying to build Lib/Transform/Proj4 without Alien is causing me some > difficulty. > > The problem arises in the Inline-generated _Inline/build/Alien/Proj4_e243 > directory because the Makefile.PL in that directory specifies: > 'INC' => '-I"C:/sisyphusion/PDL-2.007_13/Lib/Transform/Proj4" > "-IC:\\sisyphusion\\PDL-2.007_13\\Lib\\GIS\\Proj\\include"', > > which instead needs to specify "-IC:/MinGW/msys/1.0/local/include" ahead > of > "-IC:\\sisyphusion\\PDL-2.007_13\\Lib\\GIS\\Proj\\include". > > I've managed to get $hash{INC} set correctly in > Lib/Transform/Proj4/Makefile.PL - but it's not being transferred to the > Makefile.PL that Inline generates. > > Is this Inline stuff intended to be *only* for Alien builds ? If so - how > do > I circumvent it ? If not - how do I influence the setting of INC in the > problem Makefile.PL ? > > I had problems with the Lib/GIS/Proj Makefile.PL, too - but that has been > fixed (for me, at least) by the Lib/GIS/ProjMakefile.PL I've just pushed > to > git. > > One thing I haven't addressed is that I needed to specify "WITH_PROJ => > 1," > (in perldl.conf). Setting WITH_PROJ to undef is no longer sufficient, > though > it ought to suffice. > I thought about messing with the Lib/GIS/Proj/Makefile.PL logic that > determines whether the build can proceed .... but decided it was simpler > to > just set WITH_PROJ to 1. > > Cheers, > Rob > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > pdl-devel mailing list > pdl-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/pdl-devel > ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ pdl-devel mailing list pdl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-devel ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ pdl-devel mailing list pdl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-devel
