[Rcpp-devel] [Summary] (Was: question re: LdFlags, RcppLdFlags

Dirk Eddelbuettel edd at debian.org
Thu Oct 10 16:51:44 CEST 2013

To bring a bit of closure to this endless thread: It appear from his commit
logs that Romain made the change in his dplyRcpp project we are now supposed
to make per R Core: Demote packages from Depends: to Imports:, and import
what is needed.  

That, as best as I can tell, seems to be the way to avoid the clashes seen in
Romain's first email in this thread.

Some more questions re some possible future use below

On 10 October 2013 at 05:15, Romain Francois wrote:
| I don't particularly love macros. I much prefer templates. For example 
| in Rcpp11, I replaced thousands lines worth of macros code bloat with a 
| few dozens of lines of templates.

Good to see Romain-the-template-whiz clean up after Romain-the-macro-user. :)
And obviously I don't mind all the macros as your use of these macros gives
us all thse awesome features in Rcpp. But macros are a last resort...

| Would be easy enough to come up with a way to automatically generate 
| things automatically.
| A package author could leverage tools:::read_symbols_from_object_file, 
| i.e. here are all the symbols in Rcpp.so:
| symbols <- tools:::read_symbols_from_object_file( system.file( "libs", 
| "Rcpp.so", package = "Rcpp" ) )[,1]
| Would be easy to then come up with a naming convention, and generate the 
| registration.
| read_symbols_from_object_file is why we have been all of a sudden 
| forbidden to use functions that R exposes but "not part of the api".

Can you (portably, with all (major) compilers and OS choices) pick out
symbols even when they have attribute_hidden set as R does all over its


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

More information about the Rcpp-devel mailing list