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
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
_______________________________________________
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel