[Rcpp-devel] Compilation without libR.so ?

[romain at r-enthusiasts.com]

Hello,

Thanks for your interest in Rcpp.

Le 2013-06-14 07:07, Martin Jakt a écrit :
> Dear Rcpp developers,
>
> I'm rather new to Rcpp but am very excited by it's abilities;
> especially with
> the lower degree of effort required to combine R and C++. Thanks!
>
> However, I'm still left a bit mystified by how the source is compiled 
> and
> packages built. I have tried to read the guidelines for extending R,
> but it is
> rather long and it seems to assume knowledge of many things I don't 
> really
> understand.
>
> My situation is this. I've written some C++ code for reading bigWig 
> files (a
> binary genomic data file type) and used Rcpp to provide an R 
> interface to
> this. I can build the package using:
>
> R CMD check / build / INSTALL
>
> and that works. However, I would prefer to be able to compile and
> link the C++
> part of this using just make and a suitable Makefile. This almost 
> works, but
> the linker complains about missing references (from libRcpp). This is
> not very
> surprising as I'd expect that these should be present in libR.so. And
> I can't
> find libR.so anywhere on the system I'm using. (I don't think it is 
> present,
> and I don't have root access, so..).

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 
concern.
You can gain some control by using the Makevars, etc ...

> Which implies that R CMD is somehow able to link to libR without 
> libR.so?
> Is that possible, and if so, how is that achieved?
>
> I suspect the answer is quite simple, but it's not one that I've been
> able to
> find by googling.
>
> I also have one other question regarding documentation. Is there a 
> reference
> for the set of C++ classes and their interfaces that are defined by 
> libRcpp
> somewhere? I did try to work something out by looking at the Rcpp 
> header
> files, but that's not that straightforward.

I have a plan for a documentation website. but it is not ready.
Coming close is Dirk's doxygen digested documentation:
http://dirk.eddelbuettel.com/code/rcpp/html/index.html

This might help you, it might not. It is a matter of taste. For 
example, I don't like it so much.

> It also doesn't tell me very much about the implementation details.
> So far I'm
> mostly using information from examples here and there, and making 
> guesses as
> to behaviour.

The basic idea is that when using R types, we use their own memory, 
e.g. for a numeric vector (aka NumericVector in Rcpp) we use its double* 
to manipulate the data.
Then, the best information you'll get about implementation details is 
to follow the source code.

> 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.

> (It looks like 'the book', may have something like this, and I'm 
> planning to
> buy a copy over the weekend, but..).
>
> in any case I'd like to say thanks for the tools; I'm looking forward 
> to
> having a better understanding of them (perhaps even using R in C++, 
> it seems
> somehow so unholy..).
>
> cheers,
>
> Martin