similar to: Alternative for wildcard gnu extension in Makevars

Dirk Eddelbuettel <edd at debian.org> schreef: > On 13 May 2015 at 17:27, Jan van der Laan wrote: > | > | I have some cpp-files from another library (boost) in a subdirectory > | in my src directory (src/boost_src). I include these using the > | following two lines in my Makevars: > | > | SOURCES = $(wildcard *.cpp boost_src/*.cpp) > | OBJECTS = $(SOURCES:.cpp=.o)

One other solution that's only a little crazy: you could have a R function within your package that generates the appropriate (portable) Makevars, and within the package `configure` script call that function. For example" R --vanilla --slave -e "source('R/makevars.R'); makevars()" And that 'makevars()' function could generate portable

On May 13, 2015, at 2:28 PM, Henrik Bengtsson <henrik.bengtsson at ucsf.edu> wrote: > While at it: 'Makevars' is an R invention (i.e. documentation of it > is only available through the R docs), correct? /Henrik > Well, it's just a Makefile fragment that gets included along with the rest of the Makefiles, so for all practical purposes it's just a Makefile which

While at it: 'Makevars' is an R invention (i.e. documentation of it is only available through the R docs), correct? /Henrik On Wed, May 13, 2015 at 10:10 AM, Kevin Ushey <kevinushey at gmail.com> wrote: > One other solution that's only a little crazy: you could have a R > function within your package that generates the appropriate (portable) > Makevars, and within the

Dear R helpers I have following input f = c(257, 520, 110). I need to generate a decreasing sequence (decreasing by 100) which will give me an input (in a tabular form) like 257, 157, 57 520, 420, 320, 220, 120, 20 110, 10 I tried the following R code f = c(257, 520, 110) yy = matrix(data = NA, nrow = 3, ncol = 6) for (i in 1:3)      {      value = NULL      for (j in 1 : 6)           {

Hi All, Can you please help me, why this code in not generating line chart? library(ggplot2) par(mfrow=c(1,3)) #qplot(TIME1, BASCHGA, data=Orange1, geom= c("point", "line"), colour= ACTTRT) unique(Orange1$REFID) -> refid for (i in refid) { Orange2 <- Orange1[i == Orange1$REFID, ] pdf('PGA.pdf') qplot(TIME1, BASCHGA, data=Orange2, geom= c("line"),

The following code crashes R (I know I shouldn't try to estimate such a model; this was a bug in some code of mine). I also tried with R-devel; same result. tab <- structure(list(dob_day = c(FALSE, FALSE, FALSE, FALSE, TRUE, TRUE, TRUE, TRUE), dob_mon = c(FALSE, FALSE, TRUE, TRUE, FALSE, FALSE, TRUE, TRUE), dob_year = c(FALSE, TRUE, FALSE, TRUE, FALSE, TRUE, FALSE, TRUE), n =

I use the following code to create two data.frames d1 and d2 from a list: types <- c("integer", "character", "double") nlines <- 10 d1 <- as.data.frame(lapply(types, do.call, list(nlines)), stringsAsFactor=FALSE) l2 <- lapply(types, do.call, list(nlines)) d2 <- as.data.frame(l2, stringsAsFactors=FALSE) I would expect d1 and d2 to be the

Hi, This commit (I?m using the mirror to have a working link) broke C++11 compilation. Before (and still now, according to the comments in the configure script), it?s sufficient to just have ?SystemRequirements: C++11? in the DESCRIPTION file. But now ?R CMD install? fails with ?C++11 standard requested but CXX11 is not defined?, which is, according to the documentation , a lie. I can?t

>>>>> Jan van der Laan <rhelp at eoos.dds.nl> >>>>> on Fri, 6 Oct 2017 12:13:39 +0200 writes: > It is actually model.matrix that crashes, not glm. Same > crash occurs with e.g. lm. > model.matrix(dob_mon ~ dob_day*dob_mon, data = tab) > also crashes R. Yes, segmentation fault. It only happens when these are *logical*

Am I correct in thinking that the ?SystemRequirements? field in a package DESCRIPTION file is purely descriptive, there are no standard elements that can be extracted by parsing it and used automatically? This field does not seem to be widely used, even for some obvious cases like backend database driver requirements, perl, perl modules, etc. It might help to have a list of possibilities. Some

I have written an R package which contains C source code (in the directory pkg/src). Only a subset of the functions in the pkg/R directory contain a .C() call to the functions in the pkg/src directory. The rest of the package will still work and be useful without the functions containing a .C() call. To compile the code in pkg/src requires the GSL library. This is detailed in the

Dear R-developers, Bioc-developers, I am working on an R package which provides a R binding to a C library, which again depends on two other "non-standard" C++ libraries. I have this libraries installed on my box of course and I specified the library location in the Makevars file. However I thinking about to make the package available to other users and wonder a) Where I should

On Apr 4, 2009, at 6:17 AM, Duncan Sands wrote: > you need to use a separate objects directory and not build directly > in the llvm-gcc tree. For some reason the Apple people placed a file > GNUmakefile in the tree which "make" chooses in preference to the > Makefile > produced by configuring. Personally I would like to see GNUmakefile > deleted. My take, you can

it appears that by default some Apple configuration is assumed, since a simple make complains GNUmakefile:16: /CoreOS/Standard/Standard.make: No such file or directory We started with a subversion checkout, in case it matters. --------------------------------------------------------------------+ Thomas Plum, Plum Hall Inc, 3 Waihona Box 44610, Kamuela HI 96743 USA tplum at plumhall.com

What is the correct way to combine multiple calls to odfCat, odfItemize, odfTable etc. inside a function? As an example lets say I have a function that needs to write two paragraphs of text and a list to the resulting odf-document (the real function has much more complex logic, but I don't think thats relevant). My first guess would be: exampleOutput <- function() {

I am just trying to adjust one of my packages so the C code builds in Windows. This is code that has been around for a long time, and I'm am only a casual reader of C, so it has had the "if it is not broken don't touch it" approach for many years. The section 1.2.1 "Using Makevars" of "Writing R extensions" starts: "Sometimes writing your own

On Saturday 04 April 2009 19:12:55 Mike Stump wrote: > On Apr 4, 2009, at 6:17 AM, Duncan Sands wrote: > > you need to use a separate objects directory and not build directly > > in the llvm-gcc tree. For some reason the Apple people placed a file > > GNUmakefile in the tree which "make" chooses in preference to the > > Makefile > > produced by

On 27 September 2016 at 09:37, Eric Deveaud wrote: | Hello, | | I'm tring to install a Rpackage that holds some C//C++ code | | as far as I understood the R library generic compilation mechanism, | compilation of C//C++ sources is controled | | 1) at system level by the ocntentos RHOME/etc/Makeconf | 2) at user level by the content of ~/.R/Makevars | 3) at package level by the content

http://cran.r-project.org/doc/manuals/R-exts.html#Configure-and-cleanup near the start of 1.2.1 Using Makevars says > There are some macros which are set whilst configuring the building of > R itself and are stored in R_HOME/etcR_ARCH/Makeconf. That makefile is > included as a Makefile after Makevars[.win], and the macros it defines > can be used in macro assignments and make command