[Rcpp-devel] question re: LdFlags, RcppLdFlags

[Romain Francois]

Le 10/10/13 04:54, Dirk Eddelbuettel a écrit :
>
> On 10 October 2013 at 04:02, Romain Francois wrote:
> | Le 10/10/13 03:53, Dirk Eddelbuettel a écrit :
> | > Ack.  If the set of functions is small and rarely changes, then registration
> | > using R's mechanism is indeed fine. Worked so far for getting Jeff and Josh's
> | > xts into RcppXts, but that hasn't really moved beyond proof of concept.
>
> "proof of concept ... at the level of the RcppXts package" in the sense that
> the package does not yet do much with the functions it imports.
>
> | That is what Rcpp11 uses too and the unit test suite is big. This works.
> |
> | Also used in Matrix, lme4.
> |
> | That's a bit more than POC level.
>
> Of course, I phrased this poorly and you promptly misunderstood.
>
> Registration of C routines has been documented well and used by lme4 and
> Matrix for several years now.
>
> But still a pain to declare 'by hand' for a bazillion functions.  I know you
> luuv your macros, but you also know how a large part of the world thinks
> about old-C-style macros.  But they get certain jobs done.

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.

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

-- 
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30