[R-pkg-devel] how to call PROJ.4 C code in a package?
ligges at statistik.tu-dortmund.de
Fri May 22 19:07:52 CEST 2015
Yes, and a CRAN team member already suggested:
"All CRAN build/test systems have proj4 installed (packages rgdal and
proj need it) and it would have been better to link to libproj as those
On 22.05.2015 16:39, Martin Maechler wrote:
>>>>>> Daniel Kelley <Dan.Kelley at Dal.Ca>
>>>>>> on Fri, 22 May 2015 10:56:21 +0000 writes:
> > The “oce” package (for oceanographic analysis) presently includes PROJ.4 C-language source code, as a way to work with map projections (see [1,2] for why I do this). It has been suggested that a separate PROJ.4 library be used instead, and that a version of that library is available on the CRAN build machines.
> > I am wondering whether anyone can advise on how “oce” should hook up with this external PROJ.4 library. As explained at , I would prefer not to require users to download and install PROJ.4 themselves. (By the way, a strict download of the official PROJ.4 is not helpful, because it is peppered with fprintf() calls that should be Rprintf() calls, and also with exit() calls that should be error() calls.)
> > I have noticed that on my OSX machine, R has proj4 stored within itself, e.g.
> > $ nm -g /Library/Frameworks/R.framework/Versions/3.2/Resources/library/proj4/libs/proj4.so | grep pj_init
> > 00000000000254d0 T _pj_init
> > 00000000000247c0 T _pj_init_ctx
> > 0000000000025680 T _pj_init_plus
> > 0000000000025510 T _pj_init_plus_ctx
> ... Well, not quite: That's not R, that was you, when you
> installed the CRAN package called 'proj4'.
> Excursion about libraries of packages, .libPaths() etc:
> Note that many R installations, notably on the Mac (your case) and on
> Windows are setup to install all packages into R's main package
> library. Under such circumstance, within R, your
> only contains one library location ('lib.loc') path with all packages in it,
> (possibly augmented with an extra one in your personal / "home" directory.)
> Other OSes, e.g. Debian or Ubuntu Linux would use separate
> libraries to install packages in, and I have personally never
> installed packages into R's own library, but rather separately.
> > and I am wondering whether I can make “oce” hook up with this. However, I don’t know if that is there just on my machine because I have the R “proj4” package installed (or perhaps “rgdal”, which also uses PROJ.4), etc.
> Indeed, you guessed correctly, this is just because you've
> installed proj4 into R's own library.
> > So, the simple question is: what do you do if a CRAN team member suggests that you remove PROJ.4 source code from your package and instead use the version that is on CRAN build computers?
> I think it would be a very good idea if you'd use the PROJ.4
> C library that is provided already by the proj4 CRAN package
> instead of shipping your own (typically slightly differing!) version.
> You possibly should collaborate with the proj4 maintainer,
> because he would have to make part of the C API available to
> other packages, and your 'oce' could then add a
> LinkingTo: proj4
> line to oce/DESCRIPTION
> I hope this gets you started in the right direction.
> Martin Maechler, ETH Zurich
> > I hope this is fairly clear, although I realize I am being probably too wordy. Let me add to the words by thanking those who have set up this email group. It is a wonderful addition to the R world. At the moment, the CRAN team probably uses up a great deal of time dealing with people like me who are stumbling a bit, to try to find the best way to do things. Members of the CRAN team have been wonderfully generous to me, in pointing out things I’ve done wrong in package development, but this seems to me to be an undue burden on them. Let’s hope that package developers can help each other!
> > Dan Kelley / Department of Oceanography / Dalhousie University / Nova Scotia / Canada
> >  — The oce package cannot pass the map-projection work to the “proj4” package, because the proj4::project() produces an error when any point in a vector of geographical locations is “off scale” for the map projection at hand. A solution is to call proj4::project() for each point in turn, using try() to find out which results should be c(NA,NA). This is slow for datasets with many points, e.g. world coastlines
> >  — “oce” needs inverse projections, so the “mapproj” package is insufficient.
> >  — Quite a few users are at government or other sites where building packages is possible, but where they do not have permission to install new libraries (such as PROJ.4) in e.g. /usr. I don’t want such users to be cut out from using the development version of “oce”, because that makes it hard for me to fix problems that they may encounter or to add new capabilities to the development version of “oce” to allow them to do their work.
> > ______________________________________________
> > R-package-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> R-package-devel at r-project.org mailing list
More information about the R-package-devel