[Rcpp-devel] useDynLib

Wow, 
Thanks!
That is extremely useful!
I hadn't found that section 1.2.1, but that is definitely something I
shouldn't have been overlooking.
Sean

On 2011-03-31, at 8:12 PM, Sean Robert McGuffee wrote:

Thanks for the info about modularity. I'll definitely be wikipedia'ing that.
Also, thanks for clarifying the package author thing--I literally was
imagining some sort of function that writes something related to packages.

You know, I can see that, esp. in the context of the rest of that section.
I'll send a suggestion to the manual maintainers to consider using a clearer
expression.

In particular with useDynLib, what type of argument(s) go(es) in it?
For example, do I literally copy a file object into it somehow?

What I have in my NAMESPACEs, and is used in the example in section 1.6.4 of
the manual, is just the name of the DLL without the extension. And it's a
symbol, rather than a string, so no quotes.

For example, say I want to link against libpng14.
On the machine I'm sitting at, it's located at:
/usr/local/lib/libpng14.a
How would I use useDynLib in that case?

Aha, you may not need to dive into "useDynLib"s dark corners after all. I only
use "useDynLib" to link to my package's own library. For linking to a library
provided by another package, such as Rcpp or a system library, I have a
src/Makevars in my package that sets the right "-l" compiler switches and
assigns them to PKG_LIBS variable. See section "1.2.1 Using Makevars" in
R-exts. It goes into way more detail than you'll need (ignore all stuff about
"configure" for now), or see how Rcpp.package.skeleton creates a Makevars file
that has all the switches to link against Rcpp's DLL. (In their case it's a
bit more general, and you may really need nothing more than
"PKG_LIBS=-lpng14".)

I admit I approach this on a need-to-know basis myself, IOW only about as far
as I need to make my code work. But it does work, and I have also seen it used
in a number of packages I've looked at, so I don't think it's too far off the
mark. Others on the list can chime in if I'm grossly misrepresenting the
linking mechanism or what you should do in your case.

Davor

| 
| > Thanks for the info about modularity. I'll definitely be wikipedia'ing that.
| > Also, thanks for clarifying the package author thing--I literally was
| > imagining some sort of function that writes something related to packages.
| 
| You know, I can see that, esp. in the context of the rest of that section. I'll send a suggestion to the manual maintainers to consider using a clearer expression.

Thanks for doing that on r-devel!  Much appreciated.
 
| > In particular with useDynLib, what type of argument(s) go(es) in it?
| > For example, do I literally copy a file object into it somehow?
| 
| What I have in my NAMESPACEs, and is used in the example in section 1.6.4 of the manual, is just the name of the DLL without the extension. And it's a symbol, rather than a string, so no quotes.
| 
| > For example, say I want to link against libpng14.
| > On the machine I'm sitting at, it's located at:
| > /usr/local/lib/libpng14.a
| > How would I use useDynLib in that case?
| 
| Aha, you may not need to dive into "useDynLib"s dark corners after all. I only use "useDynLib" to link to my package's own library. For linking to a library provided by another package, such as Rcpp or a system library, I have a src/Makevars in my package that sets the right "-l" compiler switches and assigns them to PKG_LIBS variable. See section "1.2.1 Using Makevars" in R-exts. It goes into way more detail than you'll need (ignore all stuff about "configure" for now), or see how Rcpp.package.skeleton creates a Makevars file that has all the switches to link against Rcpp's DLL. (In their case it's a bit more general, and you may really need nothing more than "PKG_LIBS=-lpng14".)

I think this is the second this has come up so I really do need to add an
example in the Rcpp-package vignette and maybe also the Rcpp-FAQ.
 
| I admit I approach this on a need-to-know basis myself, IOW only about as far as I need to make my code work. But it does work, and I have also seen it used in a number of packages I've looked at, so I don't think it's too far off the mark. Others on the list can chime in if I'm grossly misrepresenting the linking mechanism or what you should do in your case.

Indeed: 'Need-to-know' works pretty well. R is so bloody rich and featureful
than you can't possibly know everything at the same depth.  

That said, one should read the manuals, and possibly a few times over (and R
Core does add things there, so a 'ChangeLog' for each manual would be nice).
But there are always lots of examples on CRAN one can follow...

Dirk

Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com

On 1 April 2011 at 11:15, Davor Cubranic wrote:
| On 2011-03-31, at 8:12 PM, Sean Robert McGuffee wrote:
| 
| > Thanks for the info about modularity. I'll definitely be wikipedia'ing that.
| > Also, thanks for clarifying the package author thing--I literally was
| > imagining some sort of function that writes something related to packages.
| 
| You know, I can see that, esp. in the context of the rest of that section. I'll send a suggestion to the manual maintainers to consider using a clearer expression.

Thanks for doing that on r-devel!  Much appreciated.

As you saw, there was a bit of feedback, both positive and negative, but nothing from the core team. So I've no idea whether this will go anywhere or not. If you know who would be the right person to talk to, I don't mind also emailing them directly to solicit their opinion on the matter.

Davor