search for: linkingto

Hello, I've been trying to make LinkingTo work when the package linked to has c++ code. I've put dumb packages to illustrate this emails here ; http://addictedtor.free.fr/misc/linkingto Package A defines this C++ class: class A { public: A() ; ~A() ; SEXP hello() ; } ; Package B has this function : SEXP say_hello(){ A a ; r...

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 have one: &qu...

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

...ppen (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 exist, and I think ideally we would need to treat them differently. AFAIK LinkingTo is the only form of a build-time dependency, that is completely explicit, so it is relatively easy to handle. The other frequent of build-time dependency is a function call to the other package, that happens at install time. E.g. with references or R6* classes you frequently include code like this...

...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., provides type1 in pkg2.so building on the same headers. Now, pkg2 creates an external pointer to type1 using pkg1.so, and dynamically casts it and manipulates it using functions in pkg2.so. This works perfectly, because type1...

...ted 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: 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. This should be "reinstall package B", I th...

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 to access index for repository emacs Package Version Priority Depends Imports LinkingTo Suggests Enhances OS_type License File Repository TIA B.R. Stephen L

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 B also imports A and uses functions from A's sha...

...imple function below, I know it is short and simple, but having it to be defined in each CI workflow is a pain, it could be already available in tools or utils namespace. package.dependencies.dcf <- function(file = "DESCRIPTION", which = c("Depends","Imports","LinkingTo")) { stopifnot(file.exists(file), is.character(which)) which_all <- c("Depends", "Imports", "LinkingTo", "Suggests", "Enhances") if (identical(which, "all")) which <- which_all else if (identical(which, &...

...hat it > is worth, we essentially do the same in Debian. > > Sometimes you just need to rebuild. That may be the price of admission for > using the convenience of rich C++ interfaces. > Okay, so would you say that Kirill's suggestion is not overkill? Every time package B uses LinkingTo: A, R should assume it needs to rebuild B when A is updated? Duncan Murdoch

...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 Rcpp:::LdFlags(), ... Now, I'm moving away from this and the intention is that a package using Rcpp would only have to use LinkingTo: Rcpp This sets the -I flag as before to find headers from Rcpp, but this also now takes advantage of what is described in writing R extensions: http://cran.r-project.org/doc/manuals/R-exts.html#Linking-to-native-routines-in-other-packages I'm doing this in a way that, when we are not compil...

...e in Debian. > | > > | > Sometimes you just need to rebuild. That may be the price of admission for > | > using the convenience of rich C++ interfaces. > | > > | > | Okay, so would you say that Kirill's suggestion is not overkill? Every > | time package B uses LinkingTo: A, R should assume it needs to rebuild B > | when A is updated? > > Based on my experience is a "halting problem" -- i.e. cannot know ex ante. > > So "every time" would be overkill to me. Sometimes you know you must > recompile (but try to be very prudent wit...

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 -I"/some/path/to/packageA/include" only). I've also tried Depends: pack...

...need to rebuild. That may be the price of admission for >> | > | > using the convenience of rich C++ interfaces. >> | > | > >> | > | >> | > | Okay, so would you say that Kirill's suggestion is not overkill? Every >> | > | time package B uses LinkingTo: A, R should assume it needs to rebuild B >> | > | when A is updated? >> | > >> | > Based on my experience is a "halting problem" -- i.e. cannot know ex ante. >> | > >> | > So "every time" would be overkill to me. Sometimes you know...

...te-library set up in Rprofile.site where all installed packages go, and as long as my experimental version of deSolve is installed there, I'd like to install my modified copy of deSolve in a test library. However, when I try to install my test package (which includes both Depends: deSolve and LinkingTo: deSolve, in its Description file, as described in 'R Extensions'), compilation fails, because the appropriate C code cannot be found (there is also an unrelated problem in deSolve_stubs.c triggering the "unexpected ')' before '*' token" error). [test]$ R CMD INST...

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, In Sections 5.8.1 and 5.8.2 of Writing R Extensions the following pattern is suggested for getting the path to a file in another package: PKGB_PATH=‘echo ’library(packB); cat(system.file("libs", package="packB"))’ \ | ${R_HOME}/bin/R --vanilla --slave‘ Is the library(packB) really needed here? It is not needed on two systems that I have tested: Windows and Linux. What

...worth, we essentially do the same in Debian. | > | > Sometimes you just need to rebuild. That may be the price of admission for | > using the convenience of rich C++ interfaces. | > | | Okay, so would you say that Kirill's suggestion is not overkill? Every | time package B uses LinkingTo: A, R should assume it needs to rebuild B | when A is updated? Based on my experience is a "halting problem" -- i.e. cannot know ex ante. So "every time" would be overkill to me. Sometimes you know you must recompile (but try to be very prudent with public-facing API). Many...

...; Sometimes you just need to rebuild. That may be the price of admission for > | > | > using the convenience of rich C++ interfaces. > | > | > > | > | > | > | Okay, so would you say that Kirill's suggestion is not overkill? Every > | > | time package B uses LinkingTo: A, R should assume it needs to rebuild B > | > | when A is updated? > | > > | > Based on my experience is a "halting problem" -- i.e. cannot know ex ante. > | > > | > So "every time" would be overkill to me. Sometimes you know you must > | >...

...by RcppArmadillo.package.skeleton(). They are almost identical. The first one fails to passe its tests on win R-devel [3] while the second one is OK [4]. The reason of test failing in testarma1 boils down to not finding a package during tests (here RcppArmadillo) although it is well present in LinkingTo field of the DESCRIPTION file (the mechanism of the error is detailed in [5]). To make the tests pass, I had to add RcppArmadillo and r2sundials to 'Suggests:' field too (as can be seen in testarma2) In my understanding, the presence of a package name in the LinkingTo field should be s...