Skip to content

[Rcpp-devel] recommended way to use Rcpp in packages

6 messages · Douglas Bates, Romain Francois, Dirk Eddelbuettel

#
Dear package maintainers,

Some of your package fail to compile on windows 64 with the current 
versions of R and Rcpp.

It appears to be related to the Makevars.win. What to write in the 
Makevars.win file has changed over time as new advice have been given, 
etc ... so I wanted to send an email to advise what is the currently 
best way to do it.

We need two things :

- Rcpp headers : this is really easy, you just need to add the following 
line in your DESCRIPTION

LinkingTo: Rcpp

if you do this, you don't need the PKG_CPPFLAGS line in the Makevars and 
Makevars.win anymore. This is recommended as there appears to be 
problems with both backticks and the use of $shell


- linking against the library : on windows, you need to follow Brian 
Ripley's advice : http://article.gmane.org/gmane.comp.lang.r.devel/24449

and use this in your Makevars.win:

PKG_LIBS = $(shell "${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe" -e 
"Rcpp:::LdFlags()")

(this might change again in the future and we will advise again)

Please consider registering to the Rcpp-devel mailing list if you wish 
to reply to this email. 
http://lists.r-forge.r-project.org/mailman/listinfo/rcpp-devel

Please read rhe "Rcpp-package" vignette for a more complete description 
of this.

Best Regards,

Romain
#
On Fri, Jul 16, 2010 at 3:51 AM, Romain Francois
<romain at r-enthusiasts.com> wrote:
Are we expected to add

SystemRequirements: GNU make

to DESCRIPTION because of the use of $shell?
#
Le 16 juil. 2010 ? 14:40, Douglas Bates <bates at stat.wisc.edu> a ?crit :
Yes ... Thanks i keep forgetting about that.

Romain
#
On 16 July 2010 at 07:40, Douglas Bates wrote:
| Are we expected to add
| 
| SystemRequirements: GNU make
| 
| to DESCRIPTION because of the use of $shell?

Yes.
#
On 16 July 2010 at 10:51, Romain Francois wrote:
| Dear package maintainers,
| 
| Some of your package fail to compile on windows 64 with the current 
| versions of R and Rcpp.
| 
| It appears to be related to the Makevars.win. 

There are a few pieces Romain did not mention:

  -- Failure appears only to happen on the default CRAN Windows builds (32
     and 64 bit) which are _running in parallel_ to process package more
     quickly

  -- If building 'serially', the builds succeed

  -- This is probably an interaction between make and the shell / cmd.exe / ...
 
  -- This has plagued us for a while and is nothing new or recent.
 
Right now all the burden sits on Uwe Ligges as he has to change the build
settings to accomodate packages using Rcpp. He is doing that for us all, and
I would like to should out a quick 'Thanks!'. The work is appreciated.

As Romain mentioned, we have a relatively recent improvement with 'LinkingTo'
which alleviates _one_ of the _two_ calls to $(shell) in the Makefile.
Because it does remove all such calls, I am unconvinced that it will fix all
our problems now.  We are having discussion about extending LinkingTo but
that resolution mechanism is still somewhat far off.

So I join Romain in suggesting that you change how your package finds Rcpp
headers (by letting R do the work using 'LinktingTo: Rcpp' in DESCRIPTION)
during your revisions to you package. But I think there is no rush.  The best
of my knowledge, we simply do not know of a complete fix to the build process
right now.

In sum, the failures observed after the Rcpp 0.8.4 release were nothing 'new'.

| What to write in the 
| Makevars.win file has changed over time as new advice have been given, 
| etc ... so I wanted to send an email to advise what is the currently 
| best way to do it.
| 
| We need two things :
| 
| - Rcpp headers : this is really easy, you just need to add the following 
| line in your DESCRIPTION
| 
| LinkingTo: Rcpp
| 
| if you do this, you don't need the PKG_CPPFLAGS line in the Makevars and 
| Makevars.win anymore. This is recommended as there appears to be 
| problems with both backticks and the use of $shell
| 
| 
| - linking against the library : on windows, you need to follow Brian 
| Ripley's advice : http://article.gmane.org/gmane.comp.lang.r.devel/24449
| 
| and use this in your Makevars.win:
| 
| PKG_LIBS = $(shell "${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe" -e 
| "Rcpp:::LdFlags()")
| 
| (this might change again in the future and we will advise again)

This may in fact become mandatory before R 2.12 comes out in October as
multi-arch builds (i386 and x64) are coming.  So sometime during the summer
may be a good time to make this change, but there is no rush, especially as
CRAN processing is closed right now anyway.
 
| Please consider registering to the Rcpp-devel mailing list if you wish 
| to reply to this email. 
| http://lists.r-forge.r-project.org/mailman/listinfo/rcpp-devel
| 
| Please read rhe "Rcpp-package" vignette for a more complete description 
| of this.

If you're at useR, we'd be happy to discuss and detail in person. Else,
rcpp-devel is a good place for keeping this discussion.

Thanks, Dirk


| 
| Best Regards,
| 
| Romain
| 
| -- 
| Romain Francois
| Professional R Enthusiast
| +33(0) 6 28 91 30 30
| http://romainfrancois.blog.free.fr
| |- http://bit.ly/bc8jNi : Rcpp 0.8.4
| |- http://bit.ly/dz0RlX : bibtex 0.2-1
| `- http://bit.ly/a5CK2h : Les estivales 2010
|
#
And now all Rcpp-using packages have been rebuilt, and everything is in order
as it was prior to the Rcpp 0.8.4 release. 

There was no interface change, and no change was required from the side of
the packages using Rcpp. In particular, the straightforward packages
bifactorial, highlight, minqa, mvabund, sdcTable and termstr are all in good
standing with at the most an issue with the previous R release ('oldrel').

Again, thanks to Uwe for looking after the (tedious) Windows builds and for
correcting the initial hick-up.

Going forward, switching to LinkingTo: is still recommended for headers, and
updating the link instruction is probably also a good idea before R 2.12
comes out in 2 1/2 months.  Details are in Romain's earlier email, and we may
come back with updated recommendation based on what we see with our packages.