[Rcpp-devel] Compilation without libR.so ?
romain at r-enthusiasts.com
Fri Jun 14 12:32:21 CEST 2013
Le 14 juin 2013 à 10:40, Martin Jakt <mjakt at z2.keio.jp> a écrit :
> 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
Perhaps look into devtools which might help you with the process.
> 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
>>> 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
> slicing commands.
> Rcpp-devel mailing list
> Rcpp-devel at lists.r-forge.r-project.org
More information about the Rcpp-devel