[Rcpp-devel] Advice on installing CHOLMOD/Suitesparse
Douglas Bates
bates at stat.wisc.edu
Fri Aug 31 19:08:44 CEST 2012
On Fri, Aug 31, 2012 at 11:35 AM, Rodney Sparapani <rsparapa at mcw.edu> wrote:
> On 08/31/2012 11:20 AM, Douglas Bates wrote:
>>
>> We seem to be talking at crossed purposes.
>>
>> What I meant to say is that for some mysterious reason the standard R
>> configuration defines
>>
>> CPPFLAGS=-I/usr/local/include
>>
>> or
>>
>> CPPFLAGS=-I/opt/local/include
>>
>
> Actually, it is not mysterious. I just checked it with R 2.15.1
> and, if you build it with a blank CPPFLAGS in your environment, then
> within $RHOME/etc/Makeconf CPPFLAGS is blank as well. So, as I say,
> the problem was self-inflicted since our standard set up had
> CPPFLAGS=-I/opt/local/include
No. It's in the configure script for R
## We provide these defaults so that headers and libraries in
## '/usr/local' are found (by the native tools, mostly).
if test -f "/sw/etc/fink.conf"; then
: ${CPPFLAGS="-I/sw/include -I/usr/local/include"}
: ${LDFLAGS="-L/sw/lib -L/usr/local/lib"}
else
: ${CPPFLAGS="-I/usr/local/include"}
: ${LDFLAGS="-L/usr/local/${LIBnn}"}
fi
> But, that is a habit inherited from UNIX where /opt/local (or
> /usr/local) was quite necessary for all of the GNU/FOSS stuff.
> On GNU Linux, where "everything" is already included or added via
> the package manager, this is not needed and, as you suggest,
> dangerous.
>
>> whichever is available and that doesn't make sense to me because the
>> /usr/local/ or /opt/local directories are, well, local. So any
>> package that looks for header files in the form
>>
>> #include<foo/bar.h>
>>
>> where there is a foo directory in the $PKG/inst/include (source
>> package) or $PKG/include (installed package) directory will break if
>> there happens to be a/usr/local/include/foo/ directory.
>>
>> This makes being an author of packages like RcppArmadillo or RcppEigen
>> rather difficult because the author can't just deposit the header
>> files needed by those packages linking to the Rcpp* package in
>> $PKG/inst/include. He/she must anticipate what potential users may
>> have in their /usr/local/include or /opt/local/include directories.
>> One way around this, I suppose, is for me to rename
>> RcppEigen/inst/include/Eigen and RcppEigen/inst/include/unsupported to
>> other names and go in and modify every file in those directories to
>> use nonstandard names. Of course, this makes maintenance awkward.
>>
>> Your solution of changing the name in include/Eigen/CholmodSupport to
>> <suitesparse/cholmod.h> is dangerous because it can result in version
>> skew. The CHOLMOD code will be pulled from the Matrix package and the
>> headers for that version of CHOLMOD are those in RcppEigenCholmod.h
>> If you use your own headers you may end up with a different version of
>> many of the structs that are defined in those headers, with
>> unpredictable consequences.
>>
>
> It's not ideal. It was just a workaround to get RcppEigen working so
> that we can start working on a new project.
>
>> To me the cleanest way out of this is to move /opt/local/include/Eigen
>> and /opt/local/include/unsupported into a subdirectory like
>> /opt/local/include/eigen3.
>>
>
> That would definitely work. Since we always have shiny new R releases,
> I'm just upgrading to 2.15.1 with CPPFLAGS= ;o)
>
>> Did you perhaps install suitesparse and Eigen just for the purposes of
>> using RcppEigen. If so, you don't need to have them. Between the
>> Matrix package and Rcpp and RcppEigen all the necessary code is
>> provided in R packages.
>
>
> No, I have been using CHOLMOD for a long time. And, recently I have
> been using Eigen as well. But, I see your point. Everything that
> RcppEigen needs is provided (I should have checked the source
> immediately). Thanks
>
> --
> Rodney Sparapani, PhD Center for Patient Care and Outcomes Research
> Sr. Biostatistician http://www.mcw.edu/pcor
> 4 wheels good, 2 wheels better! Medical College of Wisconsin (MCW)
> WWLD?: What Would Lombardi Do? Milwaukee, WI, USA
More information about the Rcpp-devel
mailing list