Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SF#377 Release-blocker: PDL::Transform::Proj4 not building under latest dev EUMM #81

Closed
zmughal opened this issue Mar 16, 2015 · 5 comments · Fixed by #83
Closed

SF#377 Release-blocker: PDL::Transform::Proj4 not building under latest dev EUMM #81

zmughal opened this issue Mar 16, 2015 · 5 comments · Fixed by #83

Comments

@zmughal
Copy link
Member

zmughal commented Mar 16, 2015

From https://sourceforge.net/p/pdl/bugs/377/

@mohawk2
Copy link
Member

mohawk2 commented Mar 16, 2015

The text of the ticket:

Under latest EUMM (7.05_15), PDL::Transform::Proj4 (PTP for short) won't build out of the box (although if you run make several time, it then succeeds - see below).

This is because it depends on PDL::GIS::Proj (PGP for short) to build (specifically, it calls PGP's load_projection_information()). EUMM now has a two-phase build, "pure_nolink" is done in subdirs first, followed by "linkext" (which is either "dynamic" or "static"). "pure_nolink" gets done everywhere before "dynamic" (etc) is done anywhere. The problem here is that PTP's build relies on information from PGP, but that will not start successfully because it is an XS module so will not work till "dynamic" (etc) has run on it.

Short version is PTP needs to either force PGP to be fully built, or get the information out by other means, possibly via a generated file.

I am working on a solution.

@mohawk2
Copy link
Member

mohawk2 commented Mar 16, 2015

A further issue has come to light: inter-dependency between other modules. PDL::Slatec (in Lib/Slatec) wants to use PDL::MatrixOps to build. This was masked by my having an installed PDL, which slatec.pd was able to load (strictly, the distro MatrixOps.pm had been installed, which DynaLoaded the installed MatrixOps SO).

@mohawk2
Copy link
Member

mohawk2 commented Mar 17, 2015

I think the right way is to add an optional 4th element to the array-ref parameter passed to the pdlpp_postamble_int function. If given, it's an array-ref of relative directories.

Before building the given *.pd file, it will add a target pdfile_deps executed first which will do the equivalent of cd $dir;make for each given directory, serially (no parallel-build for now). This will not materially slow things down on older EUMM because those will have been already built. On the latest one, it will allow things to actually work.

The EUMM method cd is not suitable, because that can only traverse one level down. Instead it will use an EUMM oneliner of Perl, similar to:

exit(!(chdir q($dir) && !system(q($(MAKE)))))

@mohawk2
Copy link
Member

mohawk2 commented Mar 21, 2015

Sadly, the heart of this is still there. The only good news is that this isn't new, and has been there since 2.007; it was being masked on my system by having a PDL already installed:

for x in $(git tag -l v2.007\*)
do
  echo $x
  git checkout $x
  perl Makefile.PL >/dev/null 2>&1
  (cd Basic/Core/;make) >../tf-$x 2>&1
  [ -f blib/arch/auto/PDL/Core/Core.so ] ; echo $?
  make realclean >/dev/null 2>&1
done

produced "1" (ie the SO wasn't built) from 2.007 all the way up to the latest dev release. To check that the above script is correct, I ran the heart (make, check filename) on my latest attempt to fix, and while it failed (1) first time, a rerun of that heart then produced success (0).

Still working on it.

@zmughal
Copy link
Member Author

zmughal commented Mar 22, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants