[Rd] CXX_STD and configure.ac in packages

2014-03-30 Thread Martin Morgan
In C++ code for use in a R-3.1.0 package, my specific problem is that I would 
like to use  if it is available, or  if not, 
or  if all else fails.


I (think I) can accomplish this with configure.ac as

AC_INIT("DESCRIPTION")

CXX=`"${R_HOME}/bin/R" CMD config CXX`
CXXFLAGS=`"${R_HOME}/bin/R" CMD config CXXFLAGS`

AC_CONFIG_HEADERS([src/config.h])
AC_LANG(C++)
AC_CHECK_HEADERS([unordered_map tr1/unordered_map])
AC_OUTPUT

Use of configure.ac does not seem to be entirely consistent with section 1.2.4 
of Writing R Extensions, where one is advised that to use C++(11? see below) 
code one should


CXX_STD = CXX11

in Makevars(.win). My code does not require a compiler that supports the full 
C++11 feature set. In addition, I do not understand the logic of setting a 
variable that influences compiler flags in Makevars -- configure.ac will see a 
compiler with inaccurate flags.


Is use of configure.ac orthogonal to setting CXX_STD=CXX11?

Some minor typos:

/R-3-1-branch$ svn diff
Index: doc/manual/R-exts.texi
===
--- doc/manual/R-exts.texi  (revision 65339)
+++ doc/manual/R-exts.texi  (working copy)
@@ -2250,7 +2250,7 @@
 @subsection Using C++11 code

 @R{} can be built without a C++ compiler although one is available
-(but not necessarily installed) or all known @R{} platforms.
+(but not necessarily installed) on all known @R{} platforms.
 For full portability across platforms, all
 that can be assumed is approximate support for the C++98 standard (the
 widely used @command{g++} deviates considerably from the standard).
@@ -2272,7 +2272,7 @@
 support a flag @option{-std=c++0x}, but the latter only provides partial
 support for the C++11 standard.

-In order to use C++ code in a package, the package's @file{Makevars}
+In order to use C++11 code in a package, the package's @file{Makevars}
 file (or @file{Makevars.win} on Windows) should include the line

 @example
@@ -2329,7 +2329,7 @@
 anything other than the GNU version of C++98 and GNU extensions (which
 include TR1).  The default compiler on Windows is GCC 4.6.x and supports
 the @option{-std=c++0x} flag and some C++11 features (see
-@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}.  On these
+@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}).  On these
 platforms, it is necessary to select a different compiler for C++11, as
 described above, @emph{via} personal @file{Makevars} files.  For
 example, on OS X 10.7 or later one could select @command{clang++}.

--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M1 B861
Phone: (206) 667-2793

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] CXX_STD and configure.ac in packages

2014-03-30 Thread Dirk Eddelbuettel

Hi Martin,

On 30 March 2014 at 12:50, Martin Morgan wrote:
| In C++ code for use in a R-3.1.0 package, my specific problem is that I would 
| like to use  if it is available, or  if 
not, 
| or  if all else fails.

This non-standardization over the last decade caused a lot of headaches.  

We do have a set of tests in Rcpp (see includes/Rcpp/platform/compiler.h) to
find unordered maps and sets (based on the compiler version). Not too
elegant, but it works.

One possible alternative is to simply use Boost, which is now easy thanks to
the BH package.  Then Boost abstracts this for you and you use Boost for
unordered_map and/or unordered_set.
 
| I (think I) can accomplish this with configure.ac as
| 
| AC_INIT("DESCRIPTION")
| 
| CXX=`"${R_HOME}/bin/R" CMD config CXX`
| CXXFLAGS=`"${R_HOME}/bin/R" CMD config CXXFLAGS`
| 
| AC_CONFIG_HEADERS([src/config.h])
| AC_LANG(C++)
| AC_CHECK_HEADERS([unordered_map tr1/unordered_map])
| AC_OUTPUT
| 
| Use of configure.ac does not seem to be entirely consistent with section 
1.2.4 
| of Writing R Extensions, where one is advised that to use C++(11? see below) 
| code one should
| 
|  CXX_STD = CXX11
| 
| in Makevars(.win). My code does not require a compiler that supports the full 
| C++11 feature set. In addition, I do not understand the logic of setting a 
| variable that influences compiler flags in Makevars -- configure.ac will see 
a 
| compiler with inaccurate flags.

There were some earlier discussions. Basically, R 'learns' what it has
available when it is built, and the CXX_STD = CXX11 setting then selects 
C++11 (or, on older compilers, C++0x) if available.

But you should be able to get with that. The tr1/ directory is by now pretty
old.  Looking at my current server, which has been around a few years and
upgraded, I see

edd@max:~$ ls -l /usr/include/c++/4.?/unordered_map
-rw-r--r-- 1 root root 2448 Jan 30  2013 /usr/include/c++/4.4/unordered_map
-rw-r--r-- 1 root root 1821 Jul  2  2012 /usr/include/c++/4.5/unordered_map
-rw-r--r-- 1 root root 1852 Jun 19  2013 /usr/include/c++/4.6/unordered_map
-rw-r--r-- 1 root root 1889 Sep 23  2013 /usr/include/c++/4.7/unordered_map
-rw-r--r-- 1 root root 1857 Nov 15 09:22 /usr/include/c++/4.8/unordered_map
edd@max:~$ 

Are you really going to get a compiler older than 4.4 (if in g++ world) ?

I'd try to avoid the configure dance unless you really feel you must have it.

Dirk

-- 
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[Rd] rgl question

2014-03-30 Thread Dominick Samperi
Hello,

If I call lines3d(x,y,z) I get lines connecting each point, but
when I call rgl.lines(x,y,z) I get dashed lines, and adding
something like type='l' leads to an error message. The
docs seem to suggest that rgl.lines() calls lines3d(), so
I would expect the result to be the same.

Any tips would be appreciated.

Thanks,
Dominick

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] CXX_STD and configure.ac in packages

2014-03-30 Thread Romain Francois
Hi, 

My advice would be to use SystemRequirements: C++11

As  is definitely a part of C++11, assuming this version of the 
standard gives it to you. Your package may not compile on platforms where a 
C++11 compiler is not available, but perhaps if this becomes a pattern, then 
such compilers will start to be available, as in the current version of OSX and 
recent enough versions of various linux distributions. 

The subset of feature that the version of gcc gives you with Rtools might be 
enough. 

Alternatively, if you use Rcpp, you can use the RCPP_UNORDERED_MAP macro which 
will expand to either unordered_map or tr1::unordered_map, all the condition 
compiling is done in Rcpp. 

Romain

Le 30 mars 2014 à 21:50, Martin Morgan  a écrit :

> In C++ code for use in a R-3.1.0 package, my specific problem is that I would 
> like to use  if it is available, or  if 
> not, or  if all else fails.
> 
> I (think I) can accomplish this with configure.ac as
> 
> AC_INIT("DESCRIPTION")
> 
> CXX=`"${R_HOME}/bin/R" CMD config CXX`
> CXXFLAGS=`"${R_HOME}/bin/R" CMD config CXXFLAGS`
> 
> AC_CONFIG_HEADERS([src/config.h])
> AC_LANG(C++)
> AC_CHECK_HEADERS([unordered_map tr1/unordered_map])
> AC_OUTPUT
> 
> Use of configure.ac does not seem to be entirely consistent with section 
> 1.2.4 of Writing R Extensions, where one is advised that to use C++(11? see 
> below) code one should
> 
>CXX_STD = CXX11
> 
> in Makevars(.win). My code does not require a compiler that supports the full 
> C++11 feature set. In addition, I do not understand the logic of setting a 
> variable that influences compiler flags in Makevars -- configure.ac will see 
> a compiler with inaccurate flags.
> 
> Is use of configure.ac orthogonal to setting CXX_STD=CXX11?
> 
> Some minor typos:
> 
> /R-3-1-branch$ svn diff
> Index: doc/manual/R-exts.texi
> ===
> --- doc/manual/R-exts.texi(revision 65339)
> +++ doc/manual/R-exts.texi(working copy)
> @@ -2250,7 +2250,7 @@
> @subsection Using C++11 code
> 
> @R{} can be built without a C++ compiler although one is available
> -(but not necessarily installed) or all known @R{} platforms.
> +(but not necessarily installed) on all known @R{} platforms.
> For full portability across platforms, all
> that can be assumed is approximate support for the C++98 standard (the
> widely used @command{g++} deviates considerably from the standard).
> @@ -2272,7 +2272,7 @@
> support a flag @option{-std=c++0x}, but the latter only provides partial
> support for the C++11 standard.
> 
> -In order to use C++ code in a package, the package's @file{Makevars}
> +In order to use C++11 code in a package, the package's @file{Makevars}
> file (or @file{Makevars.win} on Windows) should include the line
> 
> @example
> @@ -2329,7 +2329,7 @@
> anything other than the GNU version of C++98 and GNU extensions (which
> include TR1).  The default compiler on Windows is GCC 4.6.x and supports
> the @option{-std=c++0x} flag and some C++11 features (see
> -@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}.  On these
> +@uref{http://gcc.gnu.org/gcc-4.6/cxx0x_status.html}).  On these
> platforms, it is necessary to select a different compiler for C++11, as
> described above, @emph{via} personal @file{Makevars} files.  For
> example, on OS X 10.7 or later one could select @command{clang++}.
> 
> -- 
> Computational Biology / Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N.
> PO Box 19024 Seattle, WA 98109
> 
> Location: Arnold Building M1 B861
> Phone: (206) 667-2793
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel