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.
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?
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.
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 the
!
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
