similar to: LinkingTo and C++

Dear List, R packages may specify a "LinkingTo" attribute to specify dependencies to the source code (mainly the header files) of other packages. Unfortunately, it is not possible to also have a reference to the generated library (.dll on Windows) of the other package. So including a header file from another package to call an (exported) function will just not help. I've tried

Hello, One of our packages contains C++ code that needs to be compiled against 2 other packages. So the LinkingTo field in DESCRIPTION looks like this LinkingTo: FLCore,FLash Both packages are also in the Depends field. In R 2.6.2, first thing we noticed was that both names could not have any space between them, althoguh the example in the html version of "Writing R Extensions" does

Hi the list, In a package P1, I write a function f1 in C, potentially an internal function (not to be called from R). In a package P2, I write a function f2 in C. The f2 function needs to use f1 from P1. Is it possible ? --- 8< ---- In file P1.c --------- double f1(x,y){ .... } --- 8< ---- In file P2.c --------- void f2(x,y,z){ double result; .... result = f1(x,y); .... }

Hi I'd like to suggest to make R more informative when a user updates a package A where there's at least one package B that has "LinkingTo: A" in its description. To illustrate the problem, assume package A is updated so that its C/C++ header interface (in inst/include) is changed. For package B to pick up these changes, we need to reinstall package A. In extreme cases, if

On 16/12/2016 12:35 PM, Karl Millar wrote: > A couple of points: > - rebuilding dependent packages is needed if there is an ABI change, > not just an API change. For packages like Rcpp which export inline > functions or macros that might have changed, this is potentially any > change to existing functions, but for packages like Matrix, it isn't > really an issue at all

I am experimenting with exporting pointers to some of the functions in deSolve so that other packages may import them, using the 'R_RegisterCCallable' mechanism. I have added a header file and some other C code in inst/include of the deSolve source package that need to be accessible to other packages. I have a site-library set up in Rprofile.site where all installed packages go, and as

On 16 December 2016 at 10:14, Duncan Murdoch wrote: | On 16/12/2016 8:37 AM, Dirk Eddelbuettel wrote: | > | > On 16 December 2016 at 08:20, Duncan Murdoch wrote: | > | Perhaps the solution is to recommend that packages which export their | > | C-level entry points either guarantee them not to change or offer | > | (require?) version checks by user code. So dplyr should start out by

Hi all, Is there a fast way to determine the number of lines in a file? I'm looking for something like count.lines analogous to count.fields. Hadley -- http://had.co.nz/

On 16 December 2016 at 11:00, Duncan Murdoch wrote: | On 16/12/2016 10:40 AM, Dirk Eddelbuettel wrote: | > On 16 December 2016 at 10:14, Duncan Murdoch wrote: | > | On 16/12/2016 8:37 AM, Dirk Eddelbuettel wrote: | > | > | > | > On 16 December 2016 at 08:20, Duncan Murdoch wrote: | > | > | Perhaps the solution is to recommend that packages which export their | > | > |

I think that this problem is actually more general than just ABI versioning. The common definition of ABI refers to compiled code, but with R packages similar problems might happen (and they to happen) without any compiled code. I think the key issue is the concept of build-time dependencies. While R packages usually does not distinguish between build-time and run-time dependencies, they still do

Hi everyone, Some of you probably received the following thread from the Rcpp-devel mailing list: http://lists.r-forge.r-project.org/pipermail/rcpp-devel/2018-August/010072.html Summing up, the issue described is the following: pkg1 provides type1 in pkg1.so building on some headers. pkg2 links to pkg1 (BTW, LinkingTo is actually misleading, because it doesn't really link to it), i.e.,

I think there's one typo in your post which may confuse some readers; I've edited it inline below. My comments on the suggestion are at the bottom of the message. On 16/12/2016 5:35 AM, Kirill M?ller wrote: > Hi > > > I'd like to suggest to make R more informative when a user updates a > package A where there's at least one package B that has "LinkingTo:

On 16 December 2016 at 08:20, Duncan Murdoch wrote: | Perhaps the solution is to recommend that packages which export their | C-level entry points either guarantee them not to change or offer | (require?) version checks by user code. So dplyr should start out by | saying "I'm using Rcpp interface 0.12.8". If Rcpp has a new version | with a compatible interface, it replies

Hello, I'm currently working on making Rcpp use the feature described here more: http://cran.r-project.org/doc/manuals/R-exts.html#Linking-to-native-routines-in-other-packages To give more context, Rcpp has for a long time built what we called "the Rcpp user library", i.e. a library we could link against user the linker. We were then producing appropriate linker flag with

Hi, I need to link mypackage to 2 other packages so I can call some C functions defined in these 2 packages from mine. I've tried Depends: packageA, packageB LinkingTo: packageA, packageB as suggested by the "5.4 Registering native routines" section of the "Writing R Extensions" manual but then only packageA is seen at compilation time (gcc is called with

On 16/12/2016 8:37 AM, Dirk Eddelbuettel wrote: > > On 16 December 2016 at 08:20, Duncan Murdoch wrote: > | Perhaps the solution is to recommend that packages which export their > | C-level entry points either guarantee them not to change or offer > | (require?) version checks by user code. So dplyr should start out by > | saying "I'm using Rcpp interface 0.12.8".

On 16/12/2016 10:40 AM, Dirk Eddelbuettel wrote: > On 16 December 2016 at 10:14, Duncan Murdoch wrote: > | On 16/12/2016 8:37 AM, Dirk Eddelbuettel wrote: > | > > | > On 16 December 2016 at 08:20, Duncan Murdoch wrote: > | > | Perhaps the solution is to recommend that packages which export their > | > | C-level entry points either guarantee them not to change or offer

Hi folks, Debian 504 64-bit What is the correct syntax to check the available of a package on R repo? > available.packages("emacs", "OS_type=linux") Warning: unable to access index for repository emacs Package Version Priority Depends Imports LinkingTo Suggests Enhances OS_type License File Repository > available.packages("emacs") Warning: unable

Hello, I am trying to get a package to pass R CMD check on an iMac running Mac OS X. When the package is named safeBinaryRegression I get the following warning from R CMD check: * checking whether the name space can be loaded with stated dependencies ... WARNING Error in dyn.load(file, DLLpath = DLLpath, ...) : function 'make_lp' not provided by package 'lpSolveAPI'

We are trying to setup a Windows server that will allow any of our users to build a binary R package given a source package. The idea is to have a central R installation and allow users to install packages to their own package library for the purposes of binary package building. It seems, however, that write access to $R_HOME is required as part of the install step even when -l is used to