Giters

grailbio / rules_r

R rules for Bazel

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Add an option for R CMD install to work on a writable copy of the source files

hchauvin opened this issue · comments

commented

Having a symlinked, read-only reference to the source files can be problematic for some configure scripts, e.g., for the XML or Rgraphviz packages (they overwrite source files, they create temporary files within the source tree, ...). One quick fix is to make R CMD install work, for those packages, on a full, writable recursive copy of the source files.

I propose a new copy_srcs bool attribute to r_pkg to enable that. This would reuse the machinery of REPRODUCIBLE_BUILD and copy sources with cp -LpR ... instead of cp -a (-L dereferences symlinks).

commented

For XML, I can build just fine with 3.98-1.9 and 3.98-1.11.
For Rgraphviz version 2.22.0, the bundled graphviz software should not have contained src/graphviz/graphviz_version.h. If you delete that file, or add it in the exclude argument of the srcs glob in your BUILD file, you will be able to build the package. I will suggest modifying the auto generated BUILD file, and maybe submit a PR to the Rgraphviz package to delete the checked in file for a longer term fix.

In general, it is not a good practice to modify source files during build. In the past, I have asked packages to stop doing this. In the ~300 R packages we use at GRAIL, the only packages that needed an override to the auto generated BUILD files were GLAD (needed a config_override to say that the package directory is not called GLAD) and Rsamtools (needed post_install_files).

Creating temporary files within the source tree is fine; bazel will not complain for that.

A quick workaround when you don't want to find a proper fix for a package would be to use --spawn_strategy=standalone, but I do not want to encourage people writing configure scripts that modify source files.

commented

Thank you for this thorough answer! I wasn't happy with that either but thought about it out of necessity. You obviously have thought about it much more than I did, but for what it's worth here was my reasoning:

  • Concerning the XML package, I built it with a custom version of libxml2 to not have to depend on the system libxml2. This required me to provide some custom R/supports.R. I was misled by https://github.com/omegahat/XML at HEAD and thought that R/supports.R was distributed with the package, and that I would have to overwrite it. Actually, it is not distributed with the current version on CRAN, so my custom R/supports.R would not have to overwrite anything and copy_srcs proved to be useless here.
  • Concerning flowWorkspace, thank you for the workaround, I looked at the wrong place for the error.