similar to: R_HOME path getting munged in inst/doc/Makefile on Windows

We are trying to setup a Windows server that will allow any of our users to build a binary R package given a source package. The idea is to have a central R installation and allow users to install packages to their own package library for the purposes of binary package building. It seems, however, that write access to $R_HOME is required as part of the install step even when -l is used to

Hi, On both Unix and Windows there is a mechanism to add variables to the environment when R is started. I noticed that, on Unix, this mechanism is not used when R is started normally at the command line but only when it's started using the 'R CMD' syntax. One problem with this is some lack of consistent cross-platform behaviour. For example: On Linux: $ echo $TEXINPUTS $

Hello, I'm seeing three different vignette-related errors with recent versions of R-3.0.0 alpha. First, with the package BitSeq (http://bioconductor.org/packages/2.12/bioc/html/BitSeq.html), I get the following when trying to build the package: Error: processing vignette ?BitSeq.Rnw' failed with diagnostics: Failed to locate the ?weave? output file (by engine ?utils::Sweave?) for

Hi, Why isn't 'R CMD check --force-multiarch' installing the package for all the architectures that are going to be checked? For some packages, it only installs for the default arch ('i386'). Then testing the package for 'x64' fails. For example, Output of R CMD check --force-multiarch fabia_1.5.0.tar.gz: ----------------------------------------------------------- *

Hi, This is a follow up to: https://stat.ethz.ch/pipermail/r-devel/2010-July/057921.html The Bioconductor daily builds have been reporting a lot of strange things lately on Windows using R-2.12. This started 2 or 3 months ago and things are not getting better with recent R-2.12. Here is a sample from today's build results. We use Windows Server 2003 R2 for the 32-bit builds, Windows

Hi, The R-based version of R CMD build doesn't work for me on Windows: E:\biocbld\bbs-2.7-bioc>R\bin\R CMD build meat\Biobase * checking for file 'meat\Biobase/DESCRIPTION' ... OK * preparing 'Biobase': * checking DESCRIPTION meta-information ... OK * cleaning src * installing the package to re-build vignettes Warning in shell(sprintf("%s > %s

Hi, 'R CMD build' (with R 2.12.0 RC) fails to clean the src/ folder on Windows: D:\biocbld\bbs-2.7-bioc>ls meat/BUS/src BUS.cpp BUS.h D:\biocbld\bbs-2.7-bioc>R\bin\R CMD build meat\BUS * checking for file 'meat\BUS/DESCRIPTION' ... OK * preparing 'BUS': * checking DESCRIPTION meta-information ... OK * cleaning src * installing the package

Hi, Every day a few Bioconductor packages (different ones each day) fail to build, on Windows only, with an error like this: D:\biocbld\bbs-2.13-bioc\meat>D:\biocbld\bbs-2.13-bioc\R\bin\R.exe CMD build --keep-empty-dirs --no-resave-data OrganismDbi [...] Error in find_vignette_product(name, by = "texi2pdf", engine = engine) : Failed to locate the 'texi2pdf' output file (by

I am troubled by what appears to be a glitch in the current distribution, or in its installation on our system. I've traced it, and found a work- around. Is this normal? Is there a cleaner solution? The problem: During a package installation, the warning message "WARNING: ignoring environment value of R_HOME" from line 31 of <R_HOME>/bin/R is accidentally spliced into the

Hi, On Windows, with last R-devel tarball (r40647) from ftp://ftp.stat.math.ethz.ch/Software/R/R-devel_2007-02-04.tar.gz I get the following build error: E:\biocbld\bbs-2.0-bioc\R\src\gnuwin32> make ... ... ---------- Making package utils ------------ adding build stamp to DESCRIPTION installing NAMESPACE file and metadata installing R files Error in namespaceExport(ns, exports) :

Hi, So in an interactive R session, R.home() returns the following: > R.home() [1] "D:/biocbld/bbs-3.2-bioc/R" However, if I call it from system2(), I get different results: > system2("R", "-q -e R.home()") > R.home() [1] "D:/biocbld/BBS-3~1.2-B/R" Similarly: > system2("R", "-q -e Sys.getenv('R_HOME')") >

I am having a problem using two DLLs with the same name, but obviously located in different directories, in an R session. The troublesome package is the (Bioconductor) Rgraphviz package. It relies on (3rd party software) graphviz and imports functions from (Bioconductor) package graph. Unfortunately, the current stable release of graphviz for Windows

I'm trying to run multiple simulations using R on a cluster of pentiums running Solaris X86 by batching the R routines and simultaneously farming them out to the cluster nodes. This works fine on some of the machines, but on others the directory structure is mapped differently, so that when I try to run R, it can't be found, I can get around this by running /net/mp1/space/local/bin/R

Dear All, I would like to reset default R_HOME PATH for R.3.1.3. I installed R-devel in /usr/local/R-devel but I can't install many packages as tcltk. I uninstalled R-devel and I would reuse R.3.1.3 but the PATH is remaining to /usr/local/R-devel. I touch ~.Renviron file with R_HOME=/usr/lib/R/bin/ RSTUDIO_R_HOME=/usr/lib/R/bin/ R_LIBS=~/R/x86_64-pc-linux-gnu-library/3.1

When the R_HOME environment variable is set, R issues a warning messages when it starts up. When doing 'make check' this causes the check for eval-etc.R to fail: [...] make[3]: Leaving directory `/Volumes/app/R/src/R-1.4.0_patched_2002-01-24/tests' running strict specific tests make[3]: Entering directory `/Volumes/app/R/src/R-1.4.0_patched_2002-01-24/tests' running code in

What is the purpose of the variable R_HOME? What value should I set it to? Thanks, James [[alternative HTML version deleted]]

This is my first question to this list and possibly a bit dumb, but anyway: Can anybody tell me, where, e.g. in the "unix" reference release a DEFINITION of char * R_Home can be found? Via Defn.h the "extern" DECLARATION is everywhere, but when I derived a somewhat other main() program my linker complained about the missing definition. Thomas Hoffmann.

Just thought I would mention that the issue below (and in https://stat.ethz.ch/pipermail/r-devel/2013-April/066318.html) is still not resolved. It hasn't been a big problem, but it potentially could be, if a critical package were to have this error on release day, then all its dependencies would fail to build, which would probably require us to postpone our release. See the complete thread

Upgraded to 2.15.1 from 2.15.0 this morning, on Windows 7. I'm setting R_HOME in Control Panel, and before the upgrade, 2.15.0 recognized the value with no problems and would use it to find rprofile.site, etc. Now, after upgrade, neither .0 nor .1 recognize it at all. From the cmd line, Windows indicates it is definitely set to the value I've specified. Anyway, as a result, R is not

Dear list, It seems that a package (pkgB) using another package (pkgA) with S4 generics formed by taking existing functions (for example 'plot') must not import the existing functions ('plot') in its namespace to avoid the warning "replacing previous import: plot". Suppose we use the simple 'import' directive in the name space of pkgB. pkgA and pkgB files would