Re: [Rd] (no subject)
Henrik Bengtsson biostat.ucsf.edu> writes:
>
> On Fri, Aug 30, 2013 at 11:51 AM, Henrik Bengtsson
> biostat.ucsf.edu> wrote:
> > Hi.
[snip]
Bump ... Henrik, did you ever post this as a request/wishlist at
https://bugs.r-project.org/bugzilla3/ ? (I don't think so, I couldn't
find it there, but maybe I wasn't looking in the right place.) I
would be curious to know what the response was from R-Core, because
these kinds of warnings are starting to pop up in the nlme/lme4/
downstream package complex. In particular,
VarCorr
fixef
lmList
ranef
are defined by nlme, imported and re-exported by lme4. This doesn't
seem to make any trouble for lme4, but it does cause problems for
some of the downstream packages (such as GRRGI:
[broken URL for Gmane]
http://www.r-project.org/nosvn/R.check/
r-devel-linux-x86_64-fedora-gcc/GRRGI-00check.html )
(Right now GRRGI uses a pretty crude import-all strategy:
import(nlme,lme4,...); exportPattern("."); which might be
tweaked, but I think the issue is still worth resolving.)
In a perfect world, I guess some of these generics would be moved
upstream to a package that both nlme and lme4 could import from,
but that seems tricky to do without making fairly major architectural
changes.
Ben Bolker
> > For the record, you're referring to R-devel thread 'Correct NAMESPACE
> > approach when writing an S3 method for a generic in another package'
> > started on Aug 24, 2013
> > [https://stat.ethz.ch/pipermail/r-devel/2013-August/067221.html].
> > Yes, it's closely related or possibly the same issue. However, I do
> > not find it odd that the S3 generic function needs to be exported
> > from/available via the namespace. Hence it needs to be export():ed by
> > at least one package/namespace.
> >
> > The real issue is when two package needs to export a generic function
> > with the same name, e.g. foo(). If the two generic functions are
> > defined differently (e.g. different arguments/signatures), they will
> > be in conflict with each other. If they are identical, this should
> > not be a problem, but here I might be wrong. However, there is also
> > the special case where one package reexports the generic function from
> > another package, e.g. PkgB::foo() exports PkgA:foo(). In this case,
> > the object 'foo' does actually not existing in the name space of
> > package PkgB - instead it provides a "redirect" to it, e.g.
> >
> >> PkgA::foo
> > function (...)
> > UseMethod("foo")
> >
> >
> >> PkgB::foo
> > function (...)
> > UseMethod("foo")
> >
> >
> >> exists("foo", envir=getNamespace("PkgB"), inherits=FALSE)
> > [1] FALSE
> >
> >> exists("foo", envir=getNamespace("PkgB"), inherits=TRUE)
> > [1] TRUE
> >
> >> identical(PkgB::foo, PkgA::foo)
> > [1] TRUE
> >
> >
> > The warning on "replacing previous import by 'PkgA::foo' when loading
> > 'PkgC'" that occurs due to import(PkgA, PkgB) is generated in
> > base::namespaceImportFrom()
> > [http://svn.r-project.org/R/trunk/src/library/base/R/namespace.R]
> > Note how there is already code for avoiding "false" warnings on S4
> > generic function. This is what we'd like to have also for S3 generic
> > functions, but it's much harder to test for such since they're not
> > formally defined. However, I'd argue that it is safe to skip the
> > warning *when the variable to be imported does not actually exist in
> > the package being imported* (e.g. when just rexported), i.e.
> >
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (no subject)
Hi, it appears that you've lost the original thread
R-devel thread '"False" warning on "replacing previous import" when
re-exporting identical object' started on 2013-08-29
[https://stat.ethz.ch/pipermail/r-devel/2013-August/067321.html].
(and forgot the subject line), so in order to not start yet another
thread I'll close this one and reply/cc you there.
/Henrik
On Sat, Sep 21, 2013 at 9:44 AM, Ben Bolker wrote:
> Henrik Bengtsson biostat.ucsf.edu> writes:
>
>>
>> On Fri, Aug 30, 2013 at 11:51 AM, Henrik Bengtsson
>> biostat.ucsf.edu> wrote:
>> > Hi.
>
> [snip]
>
> Bump ... Henrik, did you ever post this as a request/wishlist at
> https://bugs.r-project.org/bugzilla3/ ? (I don't think so, I couldn't
> find it there, but maybe I wasn't looking in the right place.) I
> would be curious to know what the response was from R-Core, because
> these kinds of warnings are starting to pop up in the nlme/lme4/
> downstream package complex. In particular,
>
> VarCorr
> fixef
> lmList
> ranef
>
> are defined by nlme, imported and re-exported by lme4. This doesn't
> seem to make any trouble for lme4, but it does cause problems for
> some of the downstream packages (such as GRRGI:
> [broken URL for Gmane]
> http://www.r-project.org/nosvn/R.check/
> r-devel-linux-x86_64-fedora-gcc/GRRGI-00check.html )
>
> (Right now GRRGI uses a pretty crude import-all strategy:
> import(nlme,lme4,...); exportPattern("."); which might be
> tweaked, but I think the issue is still worth resolving.)
>
> In a perfect world, I guess some of these generics would be moved
> upstream to a package that both nlme and lme4 could import from,
> but that seems tricky to do without making fairly major architectural
> changes.
>
> Ben Bolker
>
>
>> > For the record, you're referring to R-devel thread 'Correct NAMESPACE
>> > approach when writing an S3 method for a generic in another package'
>> > started on Aug 24, 2013
>> > [https://stat.ethz.ch/pipermail/r-devel/2013-August/067221.html].
>> > Yes, it's closely related or possibly the same issue. However, I do
>> > not find it odd that the S3 generic function needs to be exported
>> > from/available via the namespace. Hence it needs to be export():ed by
>> > at least one package/namespace.
>> >
>> > The real issue is when two package needs to export a generic function
>> > with the same name, e.g. foo(). If the two generic functions are
>> > defined differently (e.g. different arguments/signatures), they will
>> > be in conflict with each other. If they are identical, this should
>> > not be a problem, but here I might be wrong. However, there is also
>> > the special case where one package reexports the generic function from
>> > another package, e.g. PkgB::foo() exports PkgA:foo(). In this case,
>> > the object 'foo' does actually not existing in the name space of
>> > package PkgB - instead it provides a "redirect" to it, e.g.
>> >
>> >> PkgA::foo
>> > function (...)
>> > UseMethod("foo")
>> >
>> >
>> >> PkgB::foo
>> > function (...)
>> > UseMethod("foo")
>> >
>> >
>> >> exists("foo", envir=getNamespace("PkgB"), inherits=FALSE)
>> > [1] FALSE
>> >
>> >> exists("foo", envir=getNamespace("PkgB"), inherits=TRUE)
>> > [1] TRUE
>> >
>> >> identical(PkgB::foo, PkgA::foo)
>> > [1] TRUE
>> >
>> >
>> > The warning on "replacing previous import by 'PkgA::foo' when loading
>> > 'PkgC'" that occurs due to import(PkgA, PkgB) is generated in
>> > base::namespaceImportFrom()
>> > [http://svn.r-project.org/R/trunk/src/library/base/R/namespace.R]
>
>> > Note how there is already code for avoiding "false" warnings on S4
>> > generic function. This is what we'd like to have also for S3 generic
>> > functions, but it's much harder to test for such since they're not
>> > formally defined. However, I'd argue that it is safe to skip the
>> > warning *when the variable to be imported does not actually exist in
>> > the package being imported* (e.g. when just rexported), i.e.
>> >
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "False" warning on "replacing previous import" when re-exporting identical object
On Sat, Sep 21, 2013 at 9:44 AM, Ben Bolker wrote:
> Henrik Bengtsson biostat.ucsf.edu> writes:
>
>>
>> On Fri, Aug 30, 2013 at 11:51 AM, Henrik Bengtsson
>> biostat.ucsf.edu> wrote:
>> > Hi.
>
> [snip]
>
> Bump ... Henrik, did you ever post this as a request/wishlist at
> https://bugs.r-project.org/bugzilla3/ ? (I don't think so, I couldn't
> find it there, but maybe I wasn't looking in the right place.) I
I submitted PR#15451:
'Bug 15451 - PATCH: namespaceImportFrom() not to warn when the
identical object is imported twice' on 2013-09-10
https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15451
There was a brief response from Prof. Ripley and then it was closed.
However, I followed up asking [cc:ing BDR and R-core] for
clarification and I gave some further arguments. There has been no
response to date.
> would be curious to know what the response was from R-Core, because
> these kinds of warnings are starting to pop up in the nlme/lme4/
> downstream package complex. In particular,
>
> VarCorr
> fixef
> lmList
> ranef
>
> are defined by nlme, imported and re-exported by lme4. This doesn't
> seem to make any trouble for lme4, but it does cause problems for
> some of the downstream packages (such as GRRGI:
> [broken URL for Gmane]
> http://www.r-project.org/nosvn/R.check/
> r-devel-linux-x86_64-fedora-gcc/GRRGI-00check.html )
>
> (Right now GRRGI uses a pretty crude import-all strategy:
> import(nlme,lme4,...); exportPattern("."); which might be
> tweaked, but I think the issue is still worth resolving.)
My interpretation of all this is that either re-exports or import():s
has to/should go. Trying to predict the future of 'R CMD check' and
re-exports are likely to cause issues as it now stands, I'd say, move
towards dropping import() and start using importFrom(). It's a
tedious move but it can be done. My issue with packages using
importFrom() is that they will be less agile for changes in APIs, e.g.
one function is moved from on package to another (of the same
"family").
>
> In a perfect world, I guess some of these generics would be moved
> upstream to a package that both nlme and lme4 could import from,
> but that seems tricky to do without making fairly major architectural
> changes.
Yes, that's a very ad hoc workaround (and not part of my perfect world
because then we get back to the time of name/argument clashes) and I
don't think you want to go there.
/Henrik
>
> Ben Bolker
On Thu, Sep 12, 2013 at 9:46 AM, Henrik Bengtsson wrote:
> Just for the record, I did submit PR#15451:
>
> 'Bug 15451 - PATCH: namespaceImportFrom() not to warn when the
> identical object is imported twice' on 2013-09-10
> https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15451
>
> /Henrik
>
> On Mon, Sep 9, 2013 at 2:37 PM, Henrik Bengtsson
> wrote:
>> Any intelligent comments on this before I submit a proposal/patch via
>> bugs.r-project.org?
>>
>> /Henrik
>>
>> On Fri, Aug 30, 2013 at 12:47 PM, Henrik Bengtsson
>> wrote:
>>> On Fri, Aug 30, 2013 at 11:51 AM, Henrik Bengtsson
>>> wrote:
Hi.
On Fri, Aug 30, 2013 at 6:58 AM, Paul Gilbert
wrote:
> This is related to the recent thread on correct NAMESPACE approach when
> writing S3 methods. If your methods are S4 I think pkgB does not need to
> export the generic. Just export the method and everything works magically
> and your problem disappears. For S3 methods there seems to be the
> difficultly you describe. Of course, the difference between S3 and S4 on
> this appears somewhat bug like. (I have not tested all this very
> carefully so I may have something wrong.)
For the record, you're referring to R-devel thread 'Correct NAMESPACE
approach when writing an S3 method for a generic in another package'
started on Aug 24, 2013
[https://stat.ethz.ch/pipermail/r-devel/2013-August/067221.html].
Yes, it's closely related or possibly the same issue. However, I do
not find it odd that the S3 generic function needs to be exported
from/available via the namespace. Hence it needs to be export():ed by
at least one package/namespace.
The real issue is when two package needs to export a generic function
with the same name, e.g. foo(). If the two generic functions are
defined differently (e.g. different arguments/signatures), they will
be in conflict with each other. If they are identical, this should
not be a problem, but here I might be wrong. However, there is also
the special case where one package reexports the generic function from
another package, e.g. PkgB::foo() exports PkgA:foo(). In this case,
the object 'foo' does actually not existing in the name space of
package PkgB - instead it provides a "redirect" to it, e.g.
> PkgA::foo
function (...)
UseMethod("foo")
> PkgB::foo
function (...)
UseMethod("foo")
> exists("foo", envir=getNames
[Rd] regenerate Rscript after moving R installation
L.S. In this bug report https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14493#c1 it is mentioned that after moving an R installation one should regenerate the Rscript executable. Is there an easy way to do so (after an R installation has been moved)? I have not found any information in the R installation and administration manual. Many thanks in advance for any pointer. Best wishes, Tobias P.S. The background to this question is the usage of Rscript calls in the Makevars files of some R packages on CRAN, so the 'broken' Rscript prevents installation of certain R packages. -- Tobias Verbeke Manager OpenAnalytics BVBA Jupiterstraat 20 2600 Antwerp Belgium E tobias.verb...@openanalytics.eu M +32 499 36 33 15 http://www.openanalytics.eu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] regenerate Rscript after moving R installation
On 21 September 2013 at 20:43, Tobias Verbeke wrote: | P.S. The background to this question is the usage of Rscript | calls in the Makevars files of some R packages on CRAN, so | the 'broken' Rscript prevents installation of certain R packages. More details, please. AFAICT there is no 'broken' Rscript per se. Eg for Rcpp, and per hints from Kurt el al over the years, we have been doing this for a few years PKG_CXXFLAGS=-I../inst/include PKG_LIBS=`$(R_HOME)/bin/Rscript -e "Rcpp:::LdFlags()"` $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) where a key part is the `$(R_HOME)/bin` which permits you to transparently switch between R-release, R-devel, R-beforeMove, R-afterMove, R-whatevr, ... simply by adjusting your shell's $PATH variable, or the R wrapper you for R CMD, or ... It. Just. Works. So if you borked your Rscript somewhere, just use another and quickly rebuild R for the new location. It is after all a cheap build (and cheaper still if you use tricks like ccache which I am a huge fan of, or 'make -j8', or ...) Dirk PS ccache is at http://ccache.samba.org/ and should be in any sane Linux distro -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] regenerate Rscript after moving R installation
Hi Dirk,
Many thanks for your reaction.
- Original Message -
> From: "Dirk Eddelbuettel"
> To: "Tobias Verbeke"
> Cc: r-devel@r-project.org
> Sent: Saturday, September 21, 2013 9:00:12 PM
> Subject: Re: [Rd] regenerate Rscript after moving R installation
>
>
> On 21 September 2013 at 20:43, Tobias Verbeke wrote:
> | P.S. The background to this question is the usage of Rscript
> | calls in the Makevars files of some R packages on CRAN, so
> | the 'broken' Rscript prevents installation of certain R packages.
>
> More details, please.
>
> AFAICT there is no 'broken' Rscript per se. Eg for Rcpp, and per hints from
> Kurt el al over the years, we have been doing this for a few years
>
> PKG_CXXFLAGS=-I../inst/include
> PKG_LIBS=`$(R_HOME)/bin/Rscript -e "Rcpp:::LdFlags()"` $(LAPACK_LIBS)
> $(BLAS_LIBS) $(FLIBS)
The package that made me discover this was RcppEigen which has indeed
PKG_LIBS=`$(R_HOME)/bin/Rscript -e "Rcpp:::LdFlags()"` $(LAPACK_LIBS)
$(BLAS_LIBS) $(FLIBS)
> where a key part is the `$(R_HOME)/bin` which permits you to transparently
> switch between R-release, R-devel, R-beforeMove, R-afterMove, R-whatevr, ...
> simply by adjusting your shell's $PATH variable, or the R wrapper you for R
> CMD, or ...
>
> It. Just. Works.
It is neat and certainly works, unless R is built on another location (on a
build machine)
prior to being put on its final location.
If I read the strace output below correctly, the origin of the problem is the
hardcoded
location of the R binary.
tobias@oa-laptop:/opt/architect/architect-stable/plugins/eu.openanalytics.architect.r.server.gtk.linux_stable/R/bin$
strace ./Rscript -e '2+2'
execve("./Rscript", ["./Rscript", "-e", "2+2"], [/* 51 vars */]) = 0
brk(0) = 0x1eb6000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fc7563e1000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=161604, ...}) = 0
mmap(NULL, 161604, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fc7563b9000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\30\2\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1811128, ...}) = 0
mmap(NULL, 3925208, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7fc755e02000
mprotect(0x7fc755fb7000, 2093056, PROT_NONE) = 0
mmap(0x7fc7561b6000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b4000) = 0x7fc7561b6000
mmap(0x7fc7561bc000, 17624, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fc7561bc000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fc7563b8000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fc7563b7000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fc7563b6000
arch_prctl(ARCH_SET_FS, 0x7fc7563b7700) = 0
mprotect(0x7fc7561b6000, 16384, PROT_READ) = 0
mprotect(0x601000, 4096, PROT_READ) = 0
mprotect(0x7fc7563e3000, 4096, PROT_READ) = 0
munmap(0x7fc7563b9000, 161604) = 0
brk(0) = 0x1eb6000
brk(0x1ed7000) = 0x1ed7000
execve("/home/builduser/architect/stable/R-build/sources/R-3.0.1/bin/R",
["/home/builduser/architect/stable/"..., "--slave", "--no-restore", "-e",
"2+2", "--args"], [/* 52 vars */]) = -1 ENOENT (No such file or directory)
dup(2) = 3
fcntl(3, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 3), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fc7563e
lseek(3, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(3, "Rscript execution error: No such"..., 51Rscript execution error: No
such file or directory
) = 51
close(3)= 0
munmap(0x7fc7563e, 4096)= 0
exit_group(-1) = ?
> So if you borked your Rscript somewhere, just use another and quickly rebuild
> R for the new location. It is after all a cheap build (and cheaper still if
> you use tricks like ccache which I am a huge fan of, or 'make -j8', or ...)
There is no way to build again since R itself is shipped (in a Debian/Ubuntu
package
and as part of Architect) prior to being installed and used on another computer.
The buildstamp that is part of the final installation path of the application
is
generated after the R build (since R is only one component), so changing the
--prefix
on the build machine would not work
Re: [Rd] regenerate Rscript after moving R installation
Tobias, On 21 September 2013 at 21:39, Tobias Verbeke wrote: | The package that made me discover this was RcppEigen which has indeed Never heard of it :) | PKG_LIBS=`$(R_HOME)/bin/Rscript -e "Rcpp:::LdFlags()"` $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) | | > where a key part is the `$(R_HOME)/bin` which permits you to transparently | > switch between R-release, R-devel, R-beforeMove, R-afterMove, R-whatevr, ... | > simply by adjusting your shell's $PATH variable, or the R wrapper you for R | > CMD, or ... | > | > It. Just. Works. | | It is neat and certainly works, unless R is built on another location (on a build machine) | prior to being put on its final location. | | If I read the strace output below correctly, the origin of the problem is the hardcoded | location of the R binary. [...] | There is no way to build again since R itself is shipped (in a Debian/Ubuntu package | and as part of Architect) prior to being installed and used on another computer. ^^ I do not know what 'Architekt' is -- but maybe you just mistakenly assume that you can mv(1) installations at will? And maybe you can't? Consider the configure --prefix=/some/location/ ... make make install where /some/location gets set at compile-time. You seem to wish it didn't. But wishing alone may not make it so. In all seriousness, these binaries may not be relocatable at will. | The buildstamp that is part of the final installation path of the application is | generated after the R build (since R is only one component), so changing the --prefix | on the build machine would not work (currently). | | I hope this gives more background to the question and would be curious if there are alternatives | to rapidly regenerate the Rscript executable only. | | (My other alternative of messing with the path in a hex editor has not been successful :-) I'd go back to rebuilding for the target location. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] regenerate Rscript after moving R installation
Hi Dirk, - Original Message - > From: "Dirk Eddelbuettel" > To: "Tobias Verbeke" > Cc: "Dirk Eddelbuettel" , r-devel@r-project.org > Sent: Saturday, September 21, 2013 11:03:37 PM > Subject: Re: [Rd] regenerate Rscript after moving R installation > > > Tobias, > > On 21 September 2013 at 21:39, Tobias Verbeke wrote: > | The package that made me discover this was RcppEigen which has indeed > > Never heard of it :) > > | PKG_LIBS=`$(R_HOME)/bin/Rscript -e "Rcpp:::LdFlags()"` $(LAPACK_LIBS) > | $(BLAS_LIBS) $(FLIBS) > | > | > where a key part is the `$(R_HOME)/bin` which permits you to > | > transparently > | > switch between R-release, R-devel, R-beforeMove, R-afterMove, R-whatevr, > | > ... > | > simply by adjusting your shell's $PATH variable, or the R wrapper you for > | > R > | > CMD, or ... > | > > | > It. Just. Works. > | > | It is neat and certainly works, unless R is built on another location (on a > | build machine) > | prior to being put on its final location. > | > | If I read the strace output below correctly, the origin of the problem is > | the hardcoded > | location of the R binary. > [...] > | There is no way to build again since R itself is shipped (in a > | Debian/Ubuntu package > | and as part of Architect) prior to being installed and used on another > | computer. > > ^^ > > I do not know what 'Architekt' is -- but maybe you just mistakenly assume Architect is a cross-platform Eclipse based R IDE with a.o. out-of-the-box Rcpp support ;-) > that you can mv(1) installations at will? And maybe you can't? Consider the > > configure --prefix=/some/location/ ... > make > make install > > where /some/location gets set at compile-time. > > You seem to wish it didn't. But wishing alone may not make it so. In all > seriousness, these binaries may not be relocatable at will. That is fair enough. I do not expect R-devel to be populated with Djinns, but was puzzled (and probably lead down the wrong path) by the fact that Rscript was the only stubborn piece in our build procedures. > | The buildstamp that is part of the final installation path of the > | application is > | generated after the R build (since R is only one component), so changing > | the --prefix > | on the build machine would not work (currently). > | > | I hope this gives more background to the question and would be curious if > | there are alternatives > | to rapidly regenerate the Rscript executable only. > | > | (My other alternative of messing with the path in a hex editor has not been > | successful :-) > > I'd go back to rebuilding for the target location. Thank you! I will report back if I find out more. Best, Tobias > > Dirk > > -- > Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] regenerate Rscript after moving R installation
On Sep 21, 2013, at 8:43 PM, Tobias Verbeke wrote: > L.S. > > In this bug report > > https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14493#c1 > > it is mentioned that after moving an R installation > one should regenerate the Rscript executable. > > Is there an easy way to do so (after an R installation has been > moved)? > You cannot move installed R. Once you run make install, there are several places in which paths get baked in - mainly Rscript and the R start script. What I typically do for deployment on the Labs machines is to use make install rhome= where is some path that I can always create a symlink in (I also use DESTDIR so that path doesn't actually need to exist on the build machine and it avoid polluting --prefix which is not needed). That way you can move R wherever you want as long so you keep that one symlink up to date. Cheers, Simon > I have not found any information in the R installation and > administration manual. > > Many thanks in advance for any pointer. > > Best wishes, > Tobias > > P.S. The background to this question is the usage of Rscript > calls in the Makevars files of some R packages on CRAN, so > the 'broken' Rscript prevents installation of certain R packages. > > -- > > Tobias Verbeke > Manager > > OpenAnalytics BVBA > Jupiterstraat 20 > 2600 Antwerp > Belgium > > E tobias.verb...@openanalytics.eu > M +32 499 36 33 15 > http://www.openanalytics.eu > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] regenerate Rscript after moving R installation
I forgot to mention that some packages bake-in paths as well, so even if you fix both R and Rscript, it will still not work in general. On Sep 22, 2013, at 3:42 AM, Simon Urbanek wrote: > On Sep 21, 2013, at 8:43 PM, Tobias Verbeke > wrote: > >> L.S. >> >> In this bug report >> >> https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14493#c1 >> >> it is mentioned that after moving an R installation >> one should regenerate the Rscript executable. >> >> Is there an easy way to do so (after an R installation has been >> moved)? >> > > You cannot move installed R. Once you run make install, there are several > places in which paths get baked in - mainly Rscript and the R start script. > What I typically do for deployment on the Labs machines is to use make > install rhome= where is some path that I can always create a > symlink in (I also use DESTDIR so that path doesn't actually need to exist on > the build machine and it avoid polluting --prefix which is not needed). That > way you can move R wherever you want as long so you keep that one symlink up > to date. > > Cheers, > Simon > > >> I have not found any information in the R installation and >> administration manual. >> >> Many thanks in advance for any pointer. >> >> Best wishes, >> Tobias >> >> P.S. The background to this question is the usage of Rscript >> calls in the Makevars files of some R packages on CRAN, so >> the 'broken' Rscript prevents installation of certain R packages. >> >> -- >> >> Tobias Verbeke >> Manager >> >> OpenAnalytics BVBA >> Jupiterstraat 20 >> 2600 Antwerp >> Belgium >> >> E tobias.verb...@openanalytics.eu >> M +32 499 36 33 15 >> http://www.openanalytics.eu >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
