[Rd] R-Project build system: DESTDIR support
Hello, I am writing you about the GNU R-Project, as part of by effort to help GNU projects provide a better, more consistent build system. Currently, your project does not support the DESTDIR variable in generated Makefiles (marked as optional in the GNU coding policies, make and automake manual). In my opinion, DESTDIR support can be very helpful for the user, the distribution-specific packagers and third-party programs, because it offers a consistent and portable way to perform staged installations. In each case, please contact me at this address <[EMAIL PROTECTED]> to provide your feedback about this issue _in any case_, should you want to support DESTDIR or not. I am ready to offer you information, help and support. Thank you for your help in making GNU projects build systems better. Claudio Fontana __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Links to non-vignette documentation
G'day all, > "HW" == hadley wickham <[EMAIL PROTECTED]> writes: >> There aren't any immediate plans to change help(package=XXX), but I >> think in the long run, if package?XXX receives wider support than it has >> now, it would make sense to make that change. HW> When was this form of package documentation created? Well, the section in "Writing R extensions" on "Documenting packages" appeared first in the version for R 2.2.0. My impression is that this form of package documentation was created in response to the following discussion: http://tolstoy.newcastle.edu.au/R/devel/05/06/index.html#1141 In particular, look at message : http://tolstoy.newcastle.edu.au/R/devel/05/06/1161.html in that thread. HW> How are users supposed to know it exists? By asking questions (or following the discussions) on r-help and r-devel? ;-)) More seriously, as Duncan pointed out in his reply, this is a relatively new feature and few packages support it. But I guess sooner or later this feature will be advertised more widely, if only because of it being again and again mentioned in discussions on r-help and r-devel. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rcpp, best method for linking to
On Fri, 24 Feb 2006, Dirk Eddelbuettel wrote: > On 24 February 2006 at 15:00, Andrew Garbutt wrote: > | Sorry, that's not quite what I was asking. I was asking more of a "best > | practice" kind of question. My own C++ codes compile fine and are > | accessible to R with some great #define magic. I was noting that the > | Rcpp package has some generic classes to handle conversion of SEXP > | structures to STL and back again. As I far as I can see, using them > | would require that I compile the C++ code into a library and link to > | that library. Or copy the code into my own code base, but doing would > | restrict myself to the GPL, as it would be a derivative work?? (IANAL) > | At this point I do not want to commit to any particular licensure for my > | package. > > I may be misunderstanding you but here it goes: if you are using Rcpp as a > means to get to R, you still end up linking with R itself. It is my > understanding that this implies the GPL -- or a suitable GPL-compatible > license -- for your code. As you know, what constitutes 'linking' and 'using' is controversial (and legal experts do not agree except perhaps that it would need to be tested in court and the interpretation may differ by country). See e.g. http://www.gnu.org/licenses/gpl-faq.html#MereAggregation for one (extremal) viewpoint which might appear to disqualify the distribution of any non-GPL R package. But there are statements in the R codebase which could be taken to be more liberal (and in the UK would be considered to have a legal bearing). R's COPYRIGHTS file says (in connection of declaring certain header files to be under LGPL). It came to our attention that some projects are interpreting GPL to mean that compiling against the header files or linking against a Windows import library brings the compiled code under the scope of GPL. This would mean it would be impossible to distribute binary versions of non-GPL packages with compiled code which called entry points in the R executable or DLL, of which there are many on CRAN. We encourage packages to be distributed under Open Source conditions, but accept that this is not possible for some contributions. Our intention is that export files and import libraries be `accessors' under clause 5 of the LGPL, so that in most cases no (additional) restrictions are imposed by compiling a package using the LGPL-ed components of R. > I do not see any _additional restriction_ coming in via the addition of > Rcpp. You already use GPL'ed object files / libraries via R itself. Plus > you're presumably building with R toolchain via 'R CMD INSTALL ' Building with a GPLed compiler does not impose license conditions on the executable, and similarly with the R toolchain on built packages, as far as I am aware. We do not currently have a mechanism for one R package to make use of the compiled code of another. When we do, the licence condition on the exporting package becomes relevant. That is already relevant for rproxy.dll, where the author chose to use LGPL. So I think there are grounds for suggesting the Rcpp might be more usable under LGPL in some circumstances. [All I am trying to do here is to point out that there are multiple viewpoints.] -- Brian D. Ripley, [EMAIL PROTECTED] 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, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-Project build system: DESTDIR support
Hi Claudio,
On 25 February 2006 at 03:11, Claudio Fontana wrote:
| Hello,
|
| I am writing you about the GNU R-Project,
| as part of by effort to help GNU projects provide a better, more
| consistent build system.
|
| Currently, your project does not support the DESTDIR variable in
| generated Makefiles (marked as optional in the GNU coding policies, make and
| automake manual).
|
| In my opinion, DESTDIR support can be very helpful for the user, the
| distribution-specific packagers and third-party programs, because it
| offers a consistent and portable way to perform staged installations.
I'm confused. We've been maintaining R in Debian quite merrily even with the
exisiting standards. To the best of my knowledge things seem to work without
DESTDIR.
In a nutshell, what we do -- and this is, or at least used to be, pretty
canonical across GNU-style packages and has been in effect for probably a
dozen years. Now, I may miss something newer happening elsewhere...
The key is that configure details the _final_ location on the installed
system, whereas 'make install' pivots off to a subdirectory in the archive of
the currently built package is 'installed' before being tarred:
./configure --prefix=/usr \
--with-system-bzlib \
[...]
--build $(buildarch)
[...]
$(MAKE) CFLAGS="$(compilerflags)" \
CXXFLAGS="$(compilerflags)" \
FFLAGS="$(compilerflags)" \
CC=${compiler} \
CXX=${cxxcompiler} \
${fortrancompiler} \
R
[...]
$(MAKE) prefix=$(debtmp)/usr\
mandir=$(debtmp)/usr/share/man \
rsharedir=$(debtmp)/usr/share/R/share \
rincludedir=$(debtmp)/usr/share/R/include \
rdocdir=$(debtmp)/usr/share/R/doc \
install
So could you detail how using DESTDIR makes this (or, for that matter,
another) use case any easier or better?
| In each case, please contact me at this address <[EMAIL PROTECTED]>
| to provide your feedback about this issue _in any case_, should you
| want to support DESTDIR or not.
|
| I am ready to offer you information, help and support.
You may want to talk to Kurt Hornik who covers the autoconf et al build
process for R. Whenever I had little gripes or needs, he reflected these
and typically with much better solutions than I could have proposed :)
| Thank you for your help in making GNU projects build systems better.
Thanks for this initiative. It could indeed makes things better
Cheers, Dirk
--
Hell, there are no rules here - we're trying to accomplish something.
-- Thomas A. Edison
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Rcpp -> RcppTemplate package with L-GPL
The R package previously named Rcpp has been renamed to
RcppTemplate (version 1.4), and it is on its way to CRAN.
This is clearer because now RcppTemplate is an R package,
RcppExample is a sample R function, and Rcpp is a C++
class library.
The new package contains the Rcpp class library released
under L-GPL instead of the more restrictive GPL, and it has
been reorganized so that it can be used like a template for
creating R packages that use C++ libraries.
In particular, the Rcpp source files have been moved from src to
inst/lib, and the static library libRcpp.a is built as part of the package
install process. It is linked against when building the package
shared library and then deleted.
See the latest RcppAPI.pdf file for more information. To view it
use vignette("RcppAPI"), or simply fetch the PDF file from
RHOME/lib/RcppTemplate/doc/RcppAPI.pdf.
Be sure to remove the old package named Rcpp if present, because
otherwise there will be two vignettes named RcppAPI, and this
confuses vignette() (chokes under Windows).
Dominick
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rcpp, best method for linking to
Brian, On 25 February 2006 at 10:07, Prof Brian Ripley wrote: | > I may be misunderstanding you but here it goes: if you are using Rcpp as a | > means to get to R, you still end up linking with R itself. It is my | > understanding that this implies the GPL -- or a suitable GPL-compatible | > license -- for your code. | | As you know, what constitutes 'linking' and 'using' is controversial (and | legal experts do not agree except perhaps that it would need to be tested | in court and the interpretation may differ by country). See e.g. [...] | [All I am trying to do here is to point out that there are multiple | viewpoints.] I appreciate the follow-up and clarification because it is indeed difficult and not fully mapped territory. But now that Dominick has released the RCpp / RCppTemplate code under LGPL, things should be easier for Andrew. It will be interesting to see what happens with GPLv3. As I understand, the murkiness with respect to linking, and things like webservice interface is said to be one of several drivers behind the license update. Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
