On Mar 12, 2013, at 2:48 PM, Hervé Pagès wrote: > On 03/12/2013 11:09 AM, Simon Urbanek wrote: >> >> On Mar 12, 2013, at 2:01 PM, Hervé Pagès wrote: >> >>> Hi, >>> >>> On 03/12/2013 09:55 AM, Simon Urbanek wrote: >>>> >>>> On Mar 12, 2013, at 12:30 PM, Kevin Horan wrote: >>>> >>>>> >>>>> Thanks for your input. To clarify, I don't need to use any part of GSL >>>>> in my R code, nor do I wish to make any part of it accessible to users of >>>>> eiR. I need it to compile other C/C++ code (LSH KIT), which I did not >>>>> write, that will itself be used in eiR. >>>>> My goal is allow the user to install eiR without also having to >>>>> install GSL before hand. >>>> >>>> If your package is on CRAN they won't need to as we are providing Mac and >>>> Windows binaries. >>> >>> I think that at least on Windows, the user would still need to have the >>> GSL installed on his/her machine. >>> >> >> Why? >> >> >>> >>>> Linux can get the binaries form their distro, so the dependencies are >>>> installed automatically. >>>> >>>> >>>>> The target audience is people in bioinformatics who may not how to >>>>> install something like GSL. It seems like what I was suggesting is not >>>>> such a good idea, if it will be hard to reliably find the header files >>>>> from another R package. I could also push all of GSL into eiR, but as GSL >>>>> has over 5000 files, this makes the package very large ( >22 MB) and >>>>> slow to compile. Both of which are a problem when submitting a package to >>>>> bioconductor. It may very well be that leaving GSL as an external >>>>> dependency to eiR is really the best and easiest way, but I just wanted >>>>> to see if there was any way to make it easier for the user. >>>> >>>> Can you clarify what you mean by "user"? The vast majority of R users use >>>> binaries, so all this is irrelevant to them as they don't need to install >>>> GSL at all. >>> >>> FWIW we currently have 7 or 8 Bioconductor packages that require the >>> GSL as an external system lib. That's because even if we provide Windows >>> binaries for those packages, those binaries are dynamically linked. >>> Is there a way to build those binaries that would avoid that dependency? >>> >> >> Yes, use static libgsl. > > Ah yes, of course. Thanks for the reminder. Just checked with Dan and > turns out that we are using that libgsl.a too (made by Brian D. Ripley) > on our build system. Some Bioconductor packages have README or INSTALL > files that still mention that the Windows user needs to install the GSL > but that doesn't seem to be the case so we'll make sure this information > gets updated. > > Also the SystemRequirements field in the DESCRIPTION file can be a > little bit confusing as it suggests that everybody requires the stuff > listed here when it actually depends whether the user is installing the > binary or not and how the binary was made. > >> >> >>> Anyway, to answer Kevin's original question: >>> >>> how do I know where the GSL library and header files, packaged >>> in GSLR, would live so I can point the compiler at them? >>> >>> Use the LinkingTo field. >>> >> >> No, you're not linking to another package, your'e linking to a *library*. >> LinkingTo uses R's own mechanism for symbol detection in another *package*. >> I know, the name is a bit misleading but those are two different things. > > I understand that but that's what Kevin wants right, i.e. linking > to another package.
No (you cannot link to another package - that's the misnomer), he wants to link to a library provided by another package (see his e-mail, he's asking about how to locate the GSL library supplied with RGSL, not to RGSL itself). > Yes there is the extra difficulty to register all the C functions in the GSL > API (as pointed out by Dirk) but that's another story. > That's not another story - that's very much part of the story why using LinkingTo is not a good idea. Cheers, Simon > Thanks, > H. > >> >> Cheers, >> Simon >> >> >>> Cheers, >>> H. >>> >>>> >>>> Cheers, >>>> Simon >>>> >>>> >>>>> So, any other suggestions about how this could be accomplished? Thanks. >>>>> >>>>> Kevin >>>>> >>>>> On 03/12/2013 05:26 AM, Simon Urbanek wrote: >>>>>> Kevin, >>>>>> >>>>>> On Mar 11, 2013, at 5:20 PM, Kevin Horan wrote: >>>>>> >>>>>>> I am developing an R package, eiR, which depends on another C library, >>>>>>> GNU scientific library (GSL). In order to make life easier for the >>>>>>> user, it would be nice to not have this as an external dependency, thus >>>>>>> I would like to wrap this library in another R package, say GSLR for >>>>>>> example. Thus far I know how to do this. The C code in eiR requires the >>>>>>> .so library and the header files from GSL in order to compile. So the >>>>>>> idea is that eiR would depend on GSLR, then GSLR gets compiled and >>>>>>> installed first, then, while eiR is installing, it should be able to >>>>>>> make use of the GSL library and header files while compiling. So my >>>>>>> question is, how do I know where the GSL library and header files, >>>>>>> packaged in GSLR, would live so I can point the compiler at them? I >>>>>>> know how to find the installed directory of an R package from within R, >>>>>>> but is there way to find that out using just Makevars or a Makefile? >>>>>>> I'm open to suggestions about a better way organize all of this as >>>>>>> well. I like t > he >>> ! >>>> idea of keeping the GSL code separate so that it can be updated/changed >>>> independently from eiR though. >>>>>> Have a look at Rcpp. >>>>>> >>>>>> >>>>>>> I'm also aware of the gsl R library on CRAN, however, this just >>>>>>> wraps GSL in R functions, but I need to use the GSL C functions in >>>>>>> other C code in eiR. >>>>>>> >>>>>> Why is what you are proposing any better than simply using GSL in eiR? >>>>>> You will still need the GSL external dependency for GSLR and you are >>>>>> only adding a lot of complexity by linking into another package's >>>>>> external directory (you cannot use libs) which is in itself very tricky >>>>>> (you'll have to deal with both static and shared version, multi-arch >>>>>> setups, possible relocation etc.). It won't make it any easier on the >>>>>> user, rather to the contrary as there will be more things to break. The >>>>>> only reason Rcpp goes into such length to do this is because it has no >>>>>> choice (the Rcpp library has to use the same libR so cannot be used as >>>>>> external dependency) - I would certainly not recommend it for something >>>>>> as trivial as providing GSL. >>>>>> >>>>>> Cheers, >>>>>> Simon >>>>>> >>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> Kevin >>>>>>> >>>>>>> ______________________________________________ >>>>>>> R-devel@r-project.org mailing list >>>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>>>>>> >>>>>>> >>>>> >>>>> >>>> >>>> ______________________________________________ >>>> R-devel@r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>>> >>> >>> -- >>> Hervé Pagès >>> >>> Program in Computational Biology >>> Division of Public Health Sciences >>> Fred Hutchinson Cancer Research Center >>> 1100 Fairview Ave. N, M1-B514 >>> P.O. Box 19024 >>> Seattle, WA 98109-1024 >>> >>> E-mail: hpa...@fhcrc.org >>> Phone: (206) 667-5791 >>> Fax: (206) 667-1319 >>> >>> ______________________________________________ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >>> >> > > -- > Hervé Pagès > > Program in Computational Biology > Division of Public Health Sciences > Fred Hutchinson Cancer Research Center > 1100 Fairview Ave. N, M1-B514 > P.O. Box 19024 > Seattle, WA 98109-1024 > > E-mail: hpa...@fhcrc.org > Phone: (206) 667-5791 > Fax: (206) 667-1319 > > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
