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 sources? Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com _______________________________________________ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
