It would be useful to be able to build PDL without the proj-dependent components. This could maybe be done using an environment variable, or an argument passed to the ```perl Makefile.PL``` call. Ed would be better placed to comment on this aspect.
Alien::proj will not attempt to build from source if it can find existing libs. If it is building from source on a system where proj>6 is installed then there might be an issue with the probes. The probe to find existing installations uses pkg-config. If that is not on your system, or the proj.pc file is not in the PKG_CONFIG_PATH, then Alien::proj will fall back to a source install. (Note - Hernán is following that up separately). Shawn. On Tue, 12 Apr 2022 at 18:06, Hernán De Angelis <variablestarli...@gmail.com> wrote: > Hello Shawn > > Thanks for your answer. > > I am not trying to build Alien::proj. I just would like to tell PDL not > to care about it. How is it that up to 2.027 this wasn't a problem but it > suddenly is in 2.028? I will dig a bit on this and try to find out. I > have a dislike of Alien::* since it will install and build things I already > have and which I have control over. This may be purely subjective but if I > can avoid having this it would be nice. Again, this wasn't a problem > before. Why now? I am not asking anyone to work to find it, my question is > rather if someone knows of an easy way to bypass having to install Alien::* > just to get PDL going, albeit without the functionality provided by proj. > > I use openSUSE Tumbleweed (rolling release). I have used Linux exclusively > since 2005, mostly openSUSE and its predecessors. For the tools I use more > often I do not use a package manager (zypper in openSUSE) but I build them > (proj, geos, gdal, GRASS GIS, QGIS and others) from source myself. All of > them live in /usr/local and subdirectories, properly exported to the path > and library path (they actually found each other, no problems there). I > normally update Perl modules using CPAN, including PDL, but when > troubleshooting is needed I also build from source using the "perl > Makefile.pl" method. And yes, I am familiar with Geo::GDAL::FFI. I use it > in a couple of projects. It installs and runs fine. > > > Best regards > > Hernán > > > > Den 2022-04-11 kl. 23:57, skrev Shawn Laffan: > > Hello Hernan, > > If you have issues installing Alien::proj then could you please file a bug > report? https://github.com/shawnlaffan/perl-alien-proj > > If you have proj installed with its headers then Alien::proj will run a > system install. This will just use your existing installation. If it > cannot find the headers then it will run a share install, which means it > builds the system from source code. > > You have not said what operating system you are using but as an example > the libproj-dev package is needed on ubuntu to trigger a system install. > > WRT Ed's comment about GDAL bindings, Geo::GDAL::FFI provides these for > perl and has methods to convert rasters to and from PDL ndarrays. > https://metacpan.org/pod/Geo::GDAL::FFI > https://metacpan.org/pod/Geo::GDAL::FFI::Band#SetPiddle > > Regards, > Shawn. > > On Tue, 12 Apr 2022 at 04:29, Hernán De Angelis < > variablestarli...@gmail.com> wrote: > >> Hi Ed >> >> Thank you for your detailed response. >> >> I understand that Alien::proj will install the latest proj. For some >> reason I cannot manage to build it. On the other hand Alien::gdal builds >> ok. >> >> I understand from your answer that PDL will build even if Alien::proj is >> not present. I wonder why then I get the error below. What could be missing >> here? >> >> I also understand that PDL has operated this way since 2014 but I have >> not had this problem before even when I update PDL every time there is a >> new upgrade and have used PDL since 2006. So something is not as it was >> recently either in PDL code or my machine. I am trying to discern what it >> is. >> >> I will investigate this a bit more and see what I can find. >> >> Again a big thank you for taking the pains of maintaining and developing >> PDL further. And even answering these emails! That's much appreciated! >> >> Minor comments: I meant FFT and not FFTW. GLUT just compiled fine, maybe >> something got changed since this morning... And please disregard the >> "whimsical" part, just a bit of misplaced humor :-) >> >> >> Best regards >> >> Hernán >> >> >> make[3]: Entering directory >> '/root/.cpan/build/PDL-2.078-0/Libtmp/Transform/Cartography' >> chmod 755 ../../blib/arch/auto/PDL/Transform/Transform.so >> Manifying 1 pod document >> make[3]: Leaving directory >> '/root/.cpan/build/PDL-2.078-0/Libtmp/Transform/Cartography' >> make[3]: Entering directory >> '/root/.cpan/build/PDL-2.078-0/Libtmp/Transform/Proj4' >> "/usr/local/perls/perl-5.34.1/bin/perl" "-I../../../blib/arch" >> "-I../../../blib/lib" >> "-MPDL::PP=PDL::Transform::Proj4,PDL::Transform::Proj4,Proj4,,1" Proj4.pd >> "/usr/local/perls/perl-5.34.1/bin/perl" -MExtUtils::Command::MM -e >> 'cp_nonempty' -- Proj4.bs >> ../../../blib/arch/auto/PDL/Transform/Proj4/Proj4.bs 644 >> /usr/local/perls/perl-5.34.1/bin/perl: symbol lookup error: >> ../../../blib/arch/auto/PDL/GIS/Proj/Proj.so: undefined symbol: >> proj_list_operations >> make[3]: *** [Makefile:863: Proj4.pm] Error 127 >> make[3]: Leaving directory >> '/root/.cpan/build/PDL-2.078-0/Libtmp/Transform/Proj4' >> make[2]: *** [Makefile:516: subdirs] Error 2 >> make[2]: Leaving directory >> '/root/.cpan/build/PDL-2.078-0/Libtmp/Transform' >> make[1]: *** [Makefile:515: subdirs] Error 2 >> make[1]: Leaving directory '/root/.cpan/build/PDL-2.078-0/Libtmp' >> make: *** [Makefile:552: subdirs] Error 2 >> >> >> >> >> >> >> >> >> Den 2022-04-11 kl. 18:12, skrev Ed .: >> >> Hi Hernán! >> >> >> >> PDL’s build (which I suspect you normally do using a tool that doesn’t >> show you these messages) is only warning you that it can’t build Proj4 or >> HDF4. It will carry on and build everything else that it can, as hopefully >> you’re seeing. You’re saying core and GSL work, which wouldn’t be true if >> everything else hadn’t built? You say “FFTW”, but there is only an “FFT” in >> PDL. https://metacpan.org/pod/PDL::FFTW3 is an external distribution, >> and is recommended over PDL::FFT. >> >> >> >> The build system was restructured last year so that the tests for those >> things now live within their submodule directories. That is the idiomatic >> way (in ExtUtils::MakeMaker-using distributions) of doing these things, and >> allowed deleting of lots of unnecessary “protection” code, since those >> tests aren’t tried if the submodule doesn’t build (which makes sense if you >> think about it). >> >> >> >> Yes, PDL needs the Alien::* stuff for this. That allows outsourcing of >> things like building (or even just finding, which is surprisingly fiddly) a >> PROJ installation to other code. If you don’t have the Alien modules >> installed, PDL works fine but without the submodules those would have >> needed. This has been how PDL has operated (not building submodules that >> don’t have needed bits) since at least the year 2014. I don’t understand >> your point about “whimsical” or Proj v9, since PDL has supported PROJ v6+ >> since version 2.064, over 3 months ago. If you have an OS-packaged PROJ v6 >> or newer, then install Alien::proj, which PDL now looks for (note, not >> Alien::Proj4), it will see the installed version and not build its own. If >> you then reinstall PDL, it will see that and build the >> PDL::Transform::Proj4 stuff (the name “Proj4” is unimportant, it’s updated >> to v6+ so don’t worry). >> >> >> >> There is certainly some demand for PDL GDAL support. The sensible way >> would be to make a separate distribution for it. I wouldn’t be surprised if >> it only needed similar code to current PDL::GIS::Proj, with the equivalent >> of wrapping a forward and backward transform with parameters. If you’d like >> to create such a thing, we (the PDL porters) can help! Join the IRC channel >> and/or email on here :-) >> >> >> >> The Fortran stuff is only warnings. You will note the submodules still >> built, passed tests and installed. The Fortran code in those submodules >> (Minuit and Slatec) are written in Fortran 77, and are dramatically >> obsolete. We may or may not remove them into separate distributions, since >> I doubt anyone uses them. Nevertheless, they still work. Minuit 2 (not yet >> supported by PDL) is written in C++. Slatec is obsolete and replaced by >> LAPACK, for which use https://metacpan.org/pod/PDL::LinearAlgebra. >> >> >> >> Please open an issue on https://github.com/Perl-GPU/OpenGL-GLUT/issues >> describing the problem you’re having with GLUT to help us fix it. My plan >> is to roll OpenGL::GLUT back into a single OpenGL distribution to ease >> installation/use. >> >> >> >> Best regards, >> >> Ed >> >> >> >> *From: *Hernán De Angelis <variablestarli...@gmail.com> >> *Sent: *11 April 2022 09:26 >> *To: *pdl-general@lists.sourceforge.net >> *Subject: *[Pdl-general] PDL 2.078 >> >> >> >> Hi all >> >> Thanks Ed and others for the great job you do maintaining and developing >> PDL. Hats off! >> >> Today I got news that 2.078 was available so I promptly went on CPAN and >> hit upgrade. But for the first time in *many* years PDL did not just build >> smoothly right away. >> >> Upon investigation I see that PDL complains about Proj4 and HDF4 lacking >> when trying to build PDL::Transform. Problem is I cannot find anywhere in >> perdl.conf where I can tell PDL not to care about this and not run the >> t/gis_proj.t and t/proj_transform.t tests. If I remember correctly that >> possibility existed years ago. Can we still build PDL without using Proj? >> Perhaps using --force? But that is not very elegant ... >> >> A related question is: does PDL really need Alien::* for this stuff? I >> would prefer not to mess with that because these packages install lots of >> stuff I do not need nor want in my system. I actually work everyday with >> geoinformatics and normally have the latest gdal/ogr and proj. If PDL needs >> proj I believe it would be much better to have PDL rely on those rather >> than some whimsical Alien::* installing ancient proj4 versions (proj is v. >> 9 now). >> >> Less serious stuff: >> - Glut fails to install at the end but this has been the case for many >> months and not been a problem >> - there are a lot of FORTRAN warnings (see exerpt below), perhaps some >> deprecated syntax that the latest gfortran (11.2.1 20220316) does not like. >> >> Good things: >> - Core, FFTW, GSL build smoothly as usual. >> >> >> Best >> >> Hernán >> >> >> >> >> # # # # # # >> # some fortran warnings >> # # # # # # >> >> Warning: Fortran 2018 deleted feature: DO termination statement which is >> not END DO or CONTINUE with label 120 at (1) >> slatec/tred2.f:112:72: >> >> 112 | 180 G = G + Z(J,K) * Z(I,K) >> >> | 1 >> Warning: Fortran 2018 deleted feature: DO termination statement which is >> not END DO or CONTINUE with label 180 at (1) >> slatec/tred2.f:118:72: >> >> 118 | 200 G = G + Z(K,J) * Z(I,K) >> >> | 1 >> Warning: Fortran 2018 deleted feature: DO termination statement which is >> not END DO or CONTINUE with label 200 at (1) >> slatec/tred2.f:131:72: >> >> 131 | DO 260 K = 1, J >> >> | 1 >> Warning: Fortran 2018 deleted feature: Shared DO termination label 260 at >> (1) >> slatec/tred2.f:149:72: >> >> 149 | 340 G = G + Z(I,K) * Z(K,J) >> >> | 1 >> Warning: Fortran 2018 deleted feature: DO termination statement which is >> not END DO or CONTINUE with label 340 at (1) >> slatec/tred2.f:151:72: >> >> 151 | DO 360 K = 1, L >> >> | 1 >> Warning: Fortran 2018 deleted feature: Shared DO termination label 360 at >> (1) >> >> >> >> >> _______________________________________________ >> pdl-general mailing list >> pdl-general@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/pdl-general >> > >
_______________________________________________ pdl-general mailing list pdl-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-general
