Support --with-data-copy as environment variable #1605
Comments
|
Shall I try this for rgdal to test a template for others? Do you have a suggested name, like: |
|
Thank you yes that would be great. The name doesn't matter for me, I think the autoconf convention is to omit the |
|
Here is a local copy of the rgdal source package, built with |
|
Hmm I trigged a build from the svn, but I don't think it worked. You can see the output here: https://github.com/r-universe/r-forge/runs/1919687390 (on the right hand under "Inspect check output"). Maybe the test autoconf line should simply be |
|
Actually on Linux it shows this, not sure if that is related |
|
No, I don't think so. The section with data_copy starts at 4014. Maybe you picked up a transient state, not 1124? On the package source, running:
I see: which is as expected, as I just committed revision 1125, using |
|
Thank you, it seems to work now: And the binary package now contains the |
|
@edzer could you copy the rgdal configure script to sf so that I can test if that resolves the issues? |
|
Up to revision 1128 - the message said |
|
No idea at all. What GDAL/PROJ versions are involved - GEOS 3.8.1, GDAL 3.1.4 and PROJ 6.3.1 (Nick Tate had trouble in class with a MacOS sf - is this release or oldrel? sf always fails on check for me locally (I never trust remote CI as you know, the links are effectively just noise because I cannot drill down to the specific failing test) because of lagging spatstat merges (my system is spatstat >= 2.0.0). If you tell me the GDAL/PROJ, I'll try to replicate. |
|
I'll try to reproduce it locally, but if it only happens for macos-oldrel on r-universe then maybe there is something out of sync on my end, and it may not happen on cran. Note that r-universe builds and checks a package using dependencies from that same universe if available. You can see this in the check log under "Build and Check for MacOS" that some of the dependency packages are downloaded from r-spatial.r-universe.dev, and the remaining ones from cran. |
|
The tab "Inspect check output" gives the output of the ./configure step: GDAL 3.2.0, PROJ 7.2.1, GEOS 3.9.0; strange enough I can't reproduce locally with 3.2.1/7.2.1/3.9.0. |
|
Nor any problem here running |
|
It may be that PROJ is not finding |
|
Maybe what is happening is that the oldrel-macos binaries from CRAN are linked against older versions of gdal/proj, whereas on r-universe we build everything with up-to-date versions. So there may be some mismatch between the versions of gdal/proj used by the different R packages. In addition, Simon was using a custom built compiler for R 3.6 that had known compatibility issues with libraries built using standard compilers. All these problems were solved for R-macos 4.0 when they switched to the standard compilers and updated their libraries. So given that R 3.6 will fall of the map in April, I wouldn't worry about it too much. |
|
OK, makes sense. Do you have a feel for 4.1 on M1? Will MacOS binary packages be dual-architecture? I see GDAL 2.4.2 and PROJ 5.2.0 for MacOS. |
|
I think it will just be a separate cran repository and package library. Almost like a separate platform. The M1 libraries are here but there hasn't been much progress, I doubt it will be ready for R 4.1: https://mac.r-project.org/libs-arm/ |
|
Right, recipes is on GDAL 3.1.4, GEOS 3.8.1 and PROJ 6.3.1. I think the libs-arm64 repo is more complete. |
# Please note that **rgdal** will be retired by the end of 2023, plan transition to sf/stars/terra functions using GDAL and PROJ at your earliest convenience. # Version 1.5-27 (development, rev. 1149-) * Correcting logic error in check for MXE UCRT builds (temporary) # Version 1.5-26 (2021-09-15, rev. 1141-1148) * Mute use of PROJ CDN for MXE UCRT builds (temporary) * Run autoupdate on configure.ac to handle obsolete AC_HELP_STRING etc. # Version 1.5-25 (2021-09-08, rev. 1122-1140) * Add environment variable access to --with-data-copy by PROJ_GDAL_DATA_COPY (r-spatial/sf#1605) * Adaptations for PROJ 8. * Handle mixed 2D/3D in readOGR(): (r-spatial/sf#1683) * Add tweak for UCRT builds. * Thin examples for spTransform(). # Version 1.5-23 (2021-02-03, rev. 1120-1121) * Further fallout after removing valgrind issues. # Version 1.5-22 (2021-02-02, rev. 1106-1119) * Attempt to remove further valgrind leak in proj6.cpp: PROJcopyEPSG() and in ogr_proj.cpp, both wrongly placed object destructors. * Modified roundtripping all declared projections in ?project examples because some listed projections for PROJ >= 5 provoke valgrind leakages by returning very large out-of-scope values for input coordinates (0, 0); inversion of these is not attempted; some listed projections are not projections. # Version 1.5-21 (2021-01-27, rev. 1093-1105) * Suggest **rgeos** to write pre-SFS multipolygon objects to avoid unpleasant workaround. * Try to eliminate current valgrind leaks, starting from (r-spatial/gstat#82). * Try to increase robustness to installation with early PROJ 6 versions, which often lack functionality found necessary later (for example visualization order); the code had assumed that this function always was available and behaved as it now does. There are now graceful failures when not available. # Version 1.5-19 (2021-01-05, rev. 1083-1092) * Dan Baston: raster speedups * PROJ 7.2.1 includes a bug-fix for `+proj=ob_tran` cases that required changes in detection and handling of target/source CRS reversal, https://lists.osgeo.org/pipermail/proj/2020-December/009999.html # Version 1.5-18 (2020-10-13, rev. 1071-1082) * condition `tests/test_enforce_xy.R` on PROJ >= 6 and GDAL >= 3 (email BDR, I forgot to re-check with PROJ-5.2.0/GDAL-2.2.4). * Adaptation to EPSG 10 database format started (from PROJ 7.2); choose DB columns by name not number in vignette. # Version 1.5-17 (2020-10-08, rev. 1051-1070) * `"CRS"` instantiation now prefers PROJ: use `rgdal::set_prefer_proj(FALSE)` to return to earlier behaviour. It seems that access from C/C++ code to mechanisms in PROJ offers more depth than going through GDAL to PROJ. This `"CRS"` instantiation in **sp** and **raster**; Proj4 and WKT2 strings may differ depending on whether instantiation is straight from PROJ or goes via GDAL. Confirmed with multiple reverse dependency checks over almost 900 CRAN packages. * By default use PROJ function to extract the source CRS from a `"BOUNDCRS"`. When `+towgs84=` is given, PROJ and GDAL see the apparent source Proj4 string as implicitly implying a coordinate operation transforming to target WGS84, leading to the WKT2 representation being a `"BOUNDCRS"`, not a `"PROJCRS"` or `"GEOGCRS"`, and thus causing misunderstandings later in searching for the most accurate coordinate operation for a transformation. May be controlled by setting the `get_source_if_boundcrs=` in `sp::CRS()` from **sp** 1.4-4 (2020-10-07). Confirmed with multiple reverse dependency checks over almost 900 CRAN packages. * Add support for instantiating from `"OGC:CRS84"` to provide a guaranteed GIS/visualization axis order WGS84 instantiator (preferred to `"EPSG:4326"`). * Permit empty string in `SRS_string=` argument to `sp::CRS()` and functions called by it. * Use GDAL `ORSIsProjected()` instead of simply looking for `"+proj=longlat"` in the Proj4 string representation where possible. # Version 1.5-16 (2020-08-07, rev. 1047-1050) * Typo in C code; use `try()` around Area-of-Interest calculation for coordinate operations (email BDR, I forgot to re-check with PROJ-5.2.0/GDAL-2.2.4). # Version 1.5-15 (2020-08-04, rev. 1020-1046) * Add support for instantiating from `"ESRI:"`. * Add Area-of-Interest to coordinate operation search (reduces the number of candidates found in many cases), and use in `rgdal::spTransform()` by default (`use_aoi=FALSE` to suppress); illustrate in vignette https://cran.r-project.org/web/packages/rgdal/vignettes/CRS_projections_transformations.html. * Harden to condition on PROJ functions only available from 6.2.0; block `"+proj=ob_tran` tests for PROJ 6.0.0-6.1.1. * Support PROJ CDN https://cdn.proj.org for on-demand download of transformation grids if requested by user; document in vignette https://cran.r-project.org/web/packages/rgdal/vignettes/CRS_projections_transformations.html. # Version 1.5-12 (2020-06-26, rev. 1007-1019) * Further corrections to `configure.ac` for older PROJ/GDAL versions # Version 1.5-10 (2020-06-09, rev. 991-1006) * Corrections to `configure.ac` for older PROJ/GDAL versions # Version 1.5-8 (2020-05-28, rev. 846-990) * Released to match **sp** 1.4.0 (2020-02-21) to 1.4-2 (2020-05-20) following months of development adapting to breaking changes in the external libraries used here: PROJ and GDAL; see also https://cran.r-project.org/web/packages/sp/news.html. * Expose `options("rgdal_show_exportToProj4_warnings"="none")` to mute Proj4 string degradation warnings. * Add new vignette https://cran.r-project.org/web/packages/rgdal/vignettes/CRS_projections_transformations.html. * CRAN Windows binary uses PROJ >= 6 and GDAL >= 3 * Add PROJ-based CRS comparison: `compare_CRS()`. * `project()` and `spTransform()` use WKT2 comment if available, fallback to Proj4 representation if not. * List coordinate operations (based on pyproj code): `list_coordOps()`. * Add `enforce_xy=` arguments to try to ensure that only GIS/visualization axis order is present. * Add `"CRS"` object comment carrying WKT2 (2019) multiline string representation on read operations. * Use `"CRS"` object comment carrying WKT2 (2019) multiline string representation on write operations.
Uh oh!
There was an error while loading. Please reload this page.
Can I do the same as
--with-data-copyby setting an environment variable rather than a configure flag?When building thousands of packages, in a complex pipeline, it is very tricky to customize the build commands for individual packages. But we can easily set global environment variables on the build server.
I am already setting
PROJ_LIBbut from what I understand, there is no variable that does the equivalent of--with-data-copy? I was first assuming that--with-data-copy=yeswas implicit when static linking but I see that is not the case. cf: #1583 (comment)The text was updated successfully, but these errors were encountered: