R CMD config --cppflags buglet

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

R CMD config --cppflags buglet

Dirk Eddelbuettel

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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD config --cppflags buglet

Brian Ripley
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@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@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,                  [hidden email]
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD config --cppflags buglet

Simon Urbanek

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

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

Cheers,
Simon

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD config --cppflags buglet

Dirk Eddelbuettel
In reply to this post by Brian Ripley

                (resending, had the CC header foobar'ed. My bad --Dirk)

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.

JGR also calls out to /usr/lib/R/share/sh/help-links.sh which is probably not
a good idea given that we have that in /usr/share/R/share/sh/help-links.sh
instead.  Given the trouble we had in Debian from calling its sibbling
/usr/share/R/share/perl/build-help.pl, I put in a kludge for that, but maybe
we should work how JGR can get this functionality via actually exported calls
(as you rightly told me that never that /usr/share/R/share/perl/build-help.pl
was not meant to be called directly).

That said, having JGR in Quantian is very nice ==:-)

| When 2.3.0 is nearer release this will need to go into the update notes.

Ok.

Thanks, Dirk

--
Hell, there are no rules here - we're trying to accomplish something.
                                                  -- Thomas A. Edison

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD config --cppflags buglet

Simon Urbanek
Dirk,

On Feb 20, 2006, at 11:22 AM, Dirk Eddelbuettel wrote:

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

Thanks for pointing this out. JGR is a completely different beast and  
unfortunately it has to hard-code things, because it is not started  
via R CMD, so it doesn't know the right paths. For non-framework  
unix, however, we can do better, because JRI now uses autoconf, so it  
can pull the paths from R at configure time.  I'll fix JRI  
correspondingly.

> JGR also calls out to /usr/lib/R/share/sh/help-links.sh which is  
> probably not a good idea given that we have that in /usr/share/R/
> share/sh/help-links.sh instead.  Given the trouble we had in Debian  
> from calling its sibbling /usr/share/R/share/perl/build-help.pl, I  
> put in a kludge for that, but maybe we should work how JGR can get  
> this functionality via actually exported calls (as you rightly told  
> me that never that /usr/share/R/share/perl/build-help.pl was not  
> meant to be called directly).
>

Another hack I suspect, but I'll have to ask Markus about this one.

Thanks,
Simon

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD config --cppflags buglet

Brian Ripley
In reply to this post by Brian Ripley
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,                  [hidden email]
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD config --cppflags buglet

Dirk Eddelbuettel
In reply to this post by Simon Urbanek

Simon, Markus,

On 20 February 2006 at 11:31, Simon Urbanek wrote:
| Dirk,
|
| On Feb 20, 2006, at 11:22 AM, Dirk Eddelbuettel wrote:
|
| > 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....
|
| Thanks for pointing this out. JGR is a completely different beast and  
| unfortunately it has to hard-code things, because it is not started  
| via R CMD, so it doesn't know the right paths. For non-framework  

Good point.

| unix, however, we can do better, because JRI now uses autoconf, so it  
| can pull the paths from R at configure time.  I'll fix JRI  
| correspondingly.

Right. Generally speaking, it built like a charm, very impressive. There is
other small gotcha. I used the .deb packages sun-j2se5.0-jdk-binary and
sun-j2se5.0-jre-binary which may do things differently from other JRE/JDK. In
any event JGR came with
  /usr/lib/j2se5.0-sun//bin/java -cp JGR.jar:. -Xmx512m org.rosuda.JGR.JGR $*
but the path ought to be /usr/lib/j2se5.0-sun/jre/bin/java (with an added
jre).  Not sure if this is worth worrying about.
|
| > JGR also calls out to /usr/lib/R/share/sh/help-links.sh which is  
| > probably not a good idea given that we have that in /usr/share/R/
| > share/sh/help-links.sh instead.  Given the trouble we had in Debian  
| > from calling its sibbling /usr/share/R/share/perl/build-help.pl, I  
| > put in a kludge for that, but maybe we should work how JGR can get  
| > this functionality via actually exported calls (as you rightly told  
| > me that never that /usr/share/R/share/perl/build-help.pl was not  
| > meant to be called directly).
| >
|
| Another hack I suspect, but I'll have to ask Markus about this one.

Can you let R's code from help.start() do the work for you?  Would be cleaner
than trying to guess where the scripts are hiding. And to Brian's point, they
shouldn't get called directly in the first place...

Dirk

--
Hell, there are no rules here - we're trying to accomplish something.
                                                  -- Thomas A. Edison

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD config --cppflags buglet

Brian Ripley
In reply to this post by Simon Urbanek
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,                  [hidden email]
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD config --cppflags buglet

Simon Urbanek
In reply to this post by Dirk Eddelbuettel

On Feb 20, 2006, at 12:01 PM, Dirk Eddelbuettel wrote:

> There is other small gotcha. I used the .deb packages sun-j2se5.0-
> jdk-binary and sun-j2se5.0-jre-binary which may do things  
> differently from other JRE/JDK. In any event JGR came with
>   /usr/lib/j2se5.0-sun//bin/java -cp JGR.jar:. -Xmx512m  
> org.rosuda.JGR.JGR $*
> but the path ought to be /usr/lib/j2se5.0-sun/jre/bin/java (with an  
> added jre).  Not sure if this is worth worrying about.


This is determined from the system, so the jre package should make  
sure its "java" is picked first, otherwise you're creating a  
dependency on jdk - i.e. make sure your jre/bin comes before jdk's  
bin in PATH and everything should be fine.

A special case is when JAVA_HOME is set - I have updated JRI such  
that it will try ${JAVA_HOME}/jre/bin before ${JAVA_HOME}/bin in such  
case.

> | Another hack I suspect, but I'll have to ask Markus about this one.
>
> Can you let R's code from help.start() do the work for you?

Maybe - Markus, can you have a look or should I do it? I didn't see  
the JGR help code for a while, but I remember some overhaul was due -  
switching to help objects should possibly solve the whole issue,  
because R will handle all the paths then.

Cheers,
Simon

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD config --cppflags buglet

Dirk Eddelbuettel

On 20 February 2006 at 13:15, Simon Urbanek wrote:
|
| On Feb 20, 2006, at 12:01 PM, Dirk Eddelbuettel wrote:
|
| > There is other small gotcha. I used the .deb packages sun-j2se5.0-
| > jdk-binary and sun-j2se5.0-jre-binary which may do things  
| > differently from other JRE/JDK. In any event JGR came with
| >   /usr/lib/j2se5.0-sun//bin/java -cp JGR.jar:. -Xmx512m  
| > org.rosuda.JGR.JGR $*
| > but the path ought to be /usr/lib/j2se5.0-sun/jre/bin/java (with an  
| > added jre).  Not sure if this is worth worrying about.
|
|
| This is determined from the system, so the jre package should make  
| sure its "java" is picked first, otherwise you're creating a  
| dependency on jdk - i.e. make sure your jre/bin comes before jdk's  
| bin in PATH and everything should be fine.

Precisely -- The trivial shell script I wrote actually calls

    cd /opt/JGR-1.3 && java -cp JGR.jar:. -Xmx512m org.rosuda.JGR.JGR $*

as 'java' is handled The Right Way (TM) by Debian's update-alternatives(8).
However, your Makefile doesn't know that and I was merely pointing out that
it pasted together a wrong path using the information it otherwise used
rather successfully to build the beast.

| A special case is when JAVA_HOME is set - I have updated JRI such  
| that it will try ${JAVA_HOME}/jre/bin before ${JAVA_HOME}/bin in such  
| case.

Exactly, that would do it !

Thanks,  Dirk

--
Hell, there are no rules here - we're trying to accomplish something.
                                                  -- Thomas A. Edison

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD config --cppflags buglet

Dirk Eddelbuettel

On 20 February 2006 at 13:07, Dirk Eddelbuettel wrote:
| Precisely -- The trivial shell script I wrote actually calls
|
|     cd /opt/JGR-1.3 && java -cp JGR.jar:. -Xmx512m org.rosuda.JGR.JGR $*
|
| as 'java' is handled The Right Way (TM) by Debian's update-alternatives(8).

That came out wrong. I meant to say something like

        "the trivial addition I made to your run script to create a
         /usr/local/bin/jgr as the following last line instead:"

The script is otherwise unaltered. Sorry for not being clearer in the first
place.

Dirk

--
Hell, there are no rules here - we're trying to accomplish something.
                                                  -- Thomas A. Edison

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel