As you may recall, a Debian user complained last year about how R is out of
line with respect to the filesystem standards (where, in essence,
architecture independent files should be in /usr/share, not /usr/lib). While
I more or less just told him to get lost, I think it was mostly BDR who
actually added support for this over the summer -- so a public Thanks!
first. As of a few weeks ago, I now activate this in the Debian builds so
that we get
edd at basebud:~> ls -F /usr/share/R
doc/ include/ share/
The downside of this that the maintained assumption of
$R_HOME/share
$R_HOME/include
no longer works.
I was updated a number of packages for Quantian yesterday and noticed that
(at least) two packages had hard-coded links to $R_HOME/include in their
Makefiles. I was just about to mail their maintainers suggesting an
alternative when I noticed that that R (2.2.1) has it wrong too:
edd at basebud:~> R CMD config --cppflags
-I/usr/lib/R/include
Should I patch this at my end with a softlink
/usr/share/R/include -> /usr/lib/R/include
or should that be fixed in R? For the record, I configure'd with
--datadir=/usr/share/R/share \
--includedir=/usr/share/R/include \
so that I get told about '-I/usr/lib/R/include' is probably a bug.
Indeed,
src/script/config has an unconditional
--cppflags)
if test -z "${LIBR}"; then
echo "R was not built as a shared library" >&2
else
echo "-I${R_HOME}/include"
fi
exit 0
so this should probably get autoconf'ed as well. R.sh.in may be in the same
boat.
I apologise in advance for not checking with R-devel which I don't have
handy
at home right now...
Regards, Dirk
--
Hell, there are no rules here - we're trying to accomplish something.
-- Thomas A. Edison
Dirk,
It was even more wrong in R-devel, for there we have sub-architectures and
it needs to be "-I${R_INCLUDE_DIR} -I${R_INCLUDE_DIR}${R_ARCH}".
Fixed now, thanks.
I don't think there is any problem in R.sh.in.
Brian
On Mon, 20 Feb 2006, Dirk Eddelbuettel wrote:
>
> As you may recall, a Debian user complained last year about how R is out of
> line with respect to the filesystem standards (where, in essence,
> architecture independent files should be in /usr/share, not /usr/lib).
While
> I more or less just told him to get lost, I think it was mostly BDR who
> actually added support for this over the summer -- so a public Thanks!
> first. As of a few weeks ago, I now activate this in the Debian builds so
> that we get
>
> edd at basebud:~> ls -F /usr/share/R
> doc/ include/ share/
>
> The downside of this that the maintained assumption of
> $R_HOME/share
> $R_HOME/include
> no longer works.
>
> I was updated a number of packages for Quantian yesterday and noticed that
> (at least) two packages had hard-coded links to $R_HOME/include in their
Well, only 5 CRAN packages have a src/Makefile, and one other has
src/Makefile.in. Of those only ROracle appears to have $R_HOME/include.
So I'm missing something.
When 2.3.0 is nearer release this will need to go into the update notes.
> Makefiles. I was just about to mail their maintainers suggesting an
> alternative when I noticed that that R (2.2.1) has it wrong too:
>
> edd at basebud:~> R CMD config --cppflags
> -I/usr/lib/R/include
>
> Should I patch this at my end with a softlink
>
> /usr/share/R/include -> /usr/lib/R/include
>
> or should that be fixed in R? For the record, I configure'd with
>
> --datadir=/usr/share/R/share \
> --includedir=/usr/share/R/include \
>
> so that I get told about '-I/usr/lib/R/include' is probably a bug.
Indeed,
> src/script/config has an unconditional
>
> --cppflags)
> if test -z "${LIBR}"; then
> echo "R was not built as a shared library" >&2
> else
> echo "-I${R_HOME}/include"
> fi
> exit 0
>
> so this should probably get autoconf'ed as well.
It should just need the right environment variables.
> R.sh.in may be in the same
> boat.
>
> I apologise in advance for not checking with R-devel which I don't have
handy
> at home right now...
>
> Regards, Dirk
>
>
--
Brian D. Ripley, ripley at stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
On Mon, 20 Feb 2006, Dirk Eddelbuettel wrote:> > Brian, Simon, > > On 20 February 2006 at 14:45, Prof Brian Ripley wrote: > | Dirk, > | > | It was even more wrong in R-devel, for there we have sub-architectures and > | it needs to be "-I${R_INCLUDE_DIR} -I${R_INCLUDE_DIR}${R_ARCH}". > | Fixed now, thanks. > > Excellent, thanks. > > | I don't think there is any problem in R.sh.in. > > Possibly a false alert, I was just grepping for R_HOME_DIR/include. Sorry > about that. > > | > I was updated a number of packages for Quantian yesterday and noticed that > | > (at least) two packages had hard-coded links to $R_HOME/include in their > | > | Well, only 5 CRAN packages have a src/Makefile, and one other has > | src/Makefile.in. Of those only ROracle appears to have $R_HOME/include. > | So I'm missing something. > > As you asked, the two failure were gnomeGUI which has a hardcoded > $R_HOME/include which could get fixed, and JGR which isn't even on CRAN.... > I didn't rebuild everything, and I never touch ROracle for lack of Oracle > headers and backends here at home.gnomeGUI is under revision. There is one version in 2.3.0/Other on CRAN, but there will be another before release. As you may have noticed, there never was a 2.2.0 version so it is still on -2.1.0. -- Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595