Thank you, Ed. I understand what you mean. I believe now that a previous version of Alien::proj was indeed present so perhaps that was causing som trouble. I also understand what you say about perldl.conf. I guess we can consider this case closed and my questions answered. Thank you all for the help.
Hernán Den tis 12 apr. 2022 18:52Ed . <ej...@hotmail.com> skrev: > Hi Hernán, > > > > Great to hear your local issue is sorted – thank you to you and Shawn! > > > > PDL absolutely will build without Alien::proj. Problems will only arise if > it is installed but broken. You can prove this by making a new Perl > installation (“perlbrew” is my recommended tool) with no Alien::proj (but > with other actual needed deps like File::Map) then install PDL on it. This > is also tested on every single commit of PDL which gets built and tested in > our continuous integration (CI) in (among many, many other environments) a > container on CentOS with minimal deps. > > > > perldl.conf as a mechanism is not a suitable vehicle for this, nor really > for anything else. The whole Alien concept in Perl was originally invented > to solve this class of problems, for PDL. We are sticking with it until a > convincing case is made for something better. > > > > Best regards, > > Ed > > > > *From: *Hernán De Angelis <variablestarli...@gmail.com> > *Sent: *12 April 2022 12:50 > *To: *pdl-general@lists.sourceforge.net > *Subject: *Re: [Pdl-general] PDL 2.078 > > > > Dear all, > > Just to report that thanks to a good collaboration with Shawn we were able > to track the problem to an empty "PKG_CONFIG_PATH" in my system. After > adding the proper paths now Alien::proj and PDL both compile fast, well and > smoothly. > > It also seems that PDL will not build without Alien::proj. Then the > question remains: would it be possible or desirable to be able to build PDL > without proj by giving an appropriate flag in perldl.conf? > > Best regards and thanks to all > > Hernán > > > > Den 2022-04-12 kl. 11:12, skrev Shawn Laffan: > > 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 > > > > >
_______________________________________________ pdl-general mailing list pdl-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-general
