[Rcpp-devel] [Bioc-devel] mzR 1.4.0 crashes R at loading

Dirk Eddelbuettel edd at debian.org
Thu Nov 22 22:22:04 CET 2012


On 22 November 2012 at 21:05, Laurent Gatto wrote:
| On 22 November 2012 20:37, Steffen Neumann <sneumann at ipb-halle.de> wrote:
| > Hi,
| >
| > thanks Dan for fixing this. I can vaguely remember
| > we've had such a problem before.
| 
| We had this issue 6 months ago, when Rcpp 0.9.12 was released (see [1]
| and commit r67124).
| 
| > Is there any way to avoid that problem in the future ?
| > Is it that BioC needs to recompile packages when
| > their dependencies change ?
| 
| As far as I understand, Bioc packages are not rebuild if dependencies
| are updated. Dan, would it be possible to add an exception and
| automatically rebuild mzR whenever a new verion of Rcpp is available?
| If not, we will have to do manually bump the version for every Rcpp
| update to avoid possible conflict - this should not be too difficult,
| as Dirk announces new Rcpp version quite widely.
| 
| > Or should we have some *maximum* Rcpp version number
| > in the mzR dependencies, so that we're forced
| > to bump the mzR version if there are new Rcpp available ?
| 
| Forcing a strict Rcpp version in the DESCRIPTION file will break mzR
| build at every Rcpp release - this is surely a stringent way to get
| the developers react in a timely fashion :-). It does however not
| happen with every new Rcpp verions - we had the problem with 0.9.12,
| now with 0.10.0, but 0.9.13 to 0.9.15 did not, I believe, require any
| package rebuild.
| 
| By the way, do other Bioc packages depending on Rcpp not suffer
| similar side effects?

I fear they do.  Uwe plays it safe and rebuilds everything in a package's
reverse dependency tree when that packages (containing compiled code)
changes. [ Which, by the way, may be overdoing it as C-only packages are
more stable. ]

But as soon as we change a structure or header somewhere, things potentiall
go boom.  We try to be careful, but we are also eager to get new "stuff" out.

So that may be collateral damage. JJ and I were just discussing the other day
how best to describe this need / minimize it among packages using Rcpp.
Generally speaking, using only 'basic types' (int, double, std::vector, ...)
and SEXPs in interfaces should help.  But it is hard to guarantee anything
here.

Dirk

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


More information about the Rcpp-devel mailing list