[Rcpp-devel] Compilation without libR.so ?
mjakt at z2.keio.jp
Fri Jun 14 10:40:25 CEST 2013
Hi Romain (?),
thanks for your quick reply,
> Why do you want that. R CMD essentially takes care all of the details,
> cooks a Makefile, runs it ... transparently. It never needs to be a
> You can gain some control by using the Makevars, etc ...
I might be doing it wrong, but I'm using:
R CMD check pkgName
which has two inconveniences:
1. It's slow
2. The compilation output gets put into a log file.
This is mostly a pain when removing all sorts of typos and stupid mistakes. I
also use colorgcc to colour output which makes things much easier to read.
I did look for a R CMD COMPILE, R CMD make
(eg. R CMD make -f Makevars), but got, 'Nothing to be done'.
I presume there's a better way, but for just making sure that the code
compiles I've not found anything better.
> I have a plan for a documentation website. but it is not ready.
> Coming close is Dirk's doxygen digested documentation:
> This might help you, it might not. It is a matter of taste. For
> example, I don't like it so much.
Wonderful. It seems to be pretty much what I'm looking for. Could perhaps do
with a little more textual description, but it is at least a good place to
start. Look forward to seeing your website as well..
> > Not really an ideal situation. For example, looking at the
> > GenericVector class, I was surprised to find push_front suggesting
> > that it
> > doesn't quite mimic the STL vector class, which I believe guarantees
> > that the
> > memory is allocated in a contiguous block (possible to combine with
> > push_front
> > and push_back, but with some difficulty).
> Those are somehow cosmetic additions. The usual suggestion is not to
> use push_front and push_back on Rcpp types.
> We use R's memory, and in R, resizing a vector means moving the data.
> So if you push_back 3 times, you're moving the data 3 times.
> Using R own memory is the best ever decision we made in Rcpp. You can
> always use your own data structures to accumulate data, perhaps using
> stl types and then convert back to R types, which is something we make
> easy to do.
that's pretty much what I'm doing; though it's rather tempting to use R Matrix
More information about the Rcpp-devel