From ripley at stats.ox.ac.uk  Mon Feb 20 18:09:08 2006
From: ripley at stats.ox.ac.uk (Prof Brian Ripley)
Date: Mon, 20 Feb 2006 17:09:08 +0000 (GMT)
Subject: [Rd] R CMD config --cppflags buglet
In-Reply-To: <DE3E9FD7-2AC8-4864-99E3-E6C7D504190D@r-project.org>
References: <17401.53474.442624.424119@basebud.nulle.part>
	<Pine.LNX.4.64.0602201431330.28459@gannet.stats.ox.ac.uk>
	<DE3E9FD7-2AC8-4864-99E3-E6C7D504190D@r-project.org>
Message-ID: <Pine.LNX.4.64.0602201458300.18227@gannet.stats.ox.ac.uk>

On Mon, 20 Feb 2006, Simon Urbanek wrote:

>
> On Feb 20, 2006, at 9:45 AM, 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.
>> 
>> 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).

/usr/share is for `architecture independent _data_' according to the 
self-styled Filesystem Hierarchy Standard.  It mentions using include for 
header files, but not that they should be `architecture independent'.

> Just curious - does that mean that ${R_INCLUDE_DIR}${R_ARCH} should actually 
> be somewhere else than in ${R_INCLUDE_DIR}, because strictly speaking it is 
> not architecture independent? It seems to me that would just make things even 
> more messy, and I'm wondering what Debian does in that case ... In fact I 
> can't even find examples for either on my Debian machines (except for Sun's 
> Java which seems to use /usr/lib as R used to) ...

I suspect on Debian the R include files actually are arch-independent. 
(The main reason that they might not be is different configuration 
options.  Suppose for a real example that you only had a 32-bit libintl on 
Sparc: then the system libintl.h is only relevant to a 32- and not a 
64-bit build, and so libintl.h needs to get installed in include/sparcv9, 
only.)  But I think the point is that /usr/share and /usr/doc may get 
shared, whereas /usr/include will not. As I recall, using R_INCLUDE_DIR 
was our idea.

Brian

-- 
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



[Rd] R CMD config --cppflags buglet
Prof Brian Ripley