[Rcpp-devel] question re: LdFlags, RcppLdFlags

[Romain Francois]

Le 09/10/13 23:43, Dirk Eddelbuettel a écrit :
>
> On 9 October 2013 at 23:13, Romain Francois wrote:
> | Le 09/10/13 03:41, Dirk Eddelbuettel a écrit :
> | >
> | > On 8 October 2013 at 16:53, Dirk Eddelbuettel wrote:
> | > | | This is also what's done in e.g. Rcpp.package.skeleton. However, following the
> | > | | new guidelines from CRAN, RcppLdFlags was exported, but not LdFlags. I wonder
> | > |
> | > | Darn.  Error on my part.  It should have been LdFlags.  That was the intent.
> | > | Oh well.
> | >
> | > Minor correction: Seems we need both. So back to export RcppLdFlags(), but
> | > thanks to Kevin also exporting LdFlags().  Done in svn rev4566.
> | >
> | > Dirk
> |
> | One good thing about the previous system was that other packages could
> | follow the same convention and also have a hidden LdFlags function
> | giving information about what is required to link against it.
> |
> | I do it, e.g. on the dplyrRcpp package.
> |
> | Now that it is exported, I get this when I load dplyrRcpp which is
> | annoying:
> |
> |
> | L'objet suivant est masqué from ‘package:Rcpp’:
> |
> |      LdFlags
>
> Gosh, that sucks.  It'll bite a few of mine too.
>
> | What would be the recommendation for such third party packages that also
> | ship a library.
>
> Don't know, and am open for suggestions.
>
> Maybe the local packages need to rename their version?

That will then quickly become a mess. Having the convention 
package:::LdFlags() was fine.

Or perhaps we could centralize within Rcpp, i.e. have something like:

PKG_LIBS = `$(R_HOME)/bin/Rscript -e "Rcpp::LdFlags('foo')"`

and we would just have to leverage the inline plugin for package "foo' 
there.

> Or maybe I got it all wrong and we get by with fewer exports?  I am (as
> usual) open for all sorts of changes at the Rcpp level (provided they don't
> break anything).
>
> | Was it really a problem that we called LdFlags with :::, did R CMD check
> | look for it in Makevars and Makevars.win ?
>
> CRAN / R Core thought so and told everybody who ran 'R CMD check' with a new
> version of R(-devel).  That has been going on for a few weeks.  Not sure if
> you regularly build r-devel or run R CMD check, but it's been there for a
> good while (and check R's NEWS commit log if you need to know more).
>
> I think R 3.0.2 may now do it too; see NEWS.
>
> And see Kevin's email from yesterday.  I had also gotten private email from
> another maintainer who apparently had CRAN yell at him over this.  <Sigh>
>
> So from the Rcpp side we have little choice but to export LdFlags() as others are
> calling it, and R CMD check now complains about the use -- unless it is exported.

Sure.

> | It is not really a problem for me, I can eliminate the need for a
> | library in dplyrRcpp.
> |
> | Would it perhaps make sense to think about standard ways for R packages
> | to register what they need. We have a system like this for inline
> | plugins, maybe it would be interesting to move this up in R and let
> | packages communicate in some way (perhaps in DESCRIPTION) what they need.
>
> Sounds good, make a proposal, get buy-in from R Core and I'll gladly adapt my
> other packages once that is implemented.
>
> Dirk

I just meant to start a discussion. I'll adapt my package so that it 
does not need to build a library.

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