Sorry for this intrusion, but I am confused by two statements that appear to conflict at some level in Writing R Extensions, and wanted to make sure I understand the answer to: Can we distribute a portable executable compiled from source by CRAN in CRAN? The following section of Writing R Extensions appears to not be addressing this issue, as in this case we are discussing portable CRAN compiled binaries, and not binaries that are submitted to CRAN: "A source package if possible should not contain binary executable files: they are not portable, and a security risk if they are of the appropriate architecture. R CMD check will warn about them unless they are listed (one filepath per line) in a file BinaryFiles at the top level of the package. Note that CRAN will no longer accept submissions containing binary files even if they are listed." The following section seems to indicate special cases in which packages can create binary files: "In very special cases packages may create binary files other than the shared objects/DLLs in the src directory. Such files will not be installed in multi-arch setting since R CMD INSTALL --libs-only is used to merge multiple architectures and it only copies shared objects/DLLs. If a package wants to install other binaries (for example executable programs), it should to provide an R script src/install.libs.R which will be run as part of the installation in the src build directory instead of copying the shared objects/DLLs." Once again, sorry for my confusion on this point. I just have what I might consider a special case where it would be very handy to distribute a cran compiled executable. Thanks! Daniel Fuka
Distributing Executables.
5 messages · Daniel Fuka, Brian Ripley, Simon Urbanek
On May 18, 2012, at 11:11 AM, Daniel Fuka wrote:
Sorry for this intrusion, but I am confused by two statements that appear to conflict at some level in Writing R Extensions, and wanted to make sure I understand the answer to: Can we distribute a portable executable compiled from source by CRAN in CRAN? The following section of Writing R Extensions appears to not be addressing this issue, as in this case we are discussing portable CRAN compiled binaries, and not binaries that are submitted to CRAN: "A source package if possible should not contain binary executable files: they are not portable, and a security risk if they are of the appropriate architecture. R CMD check will warn about them unless they are listed (one filepath per line) in a file BinaryFiles at the top level of the package. Note that CRAN will no longer accept submissions containing binary files even if they are listed." The following section seems to indicate special cases in which packages can create binary files: "In very special cases packages may create binary files other than the shared objects/DLLs in the src directory. Such files will not be installed in multi-arch setting since R CMD INSTALL --libs-only is used to merge multiple architectures and it only copies shared objects/DLLs. If a package wants to install other binaries (for example executable programs), it should to provide an R script src/install.libs.R which will be run as part of the installation in the src build directory instead of copying the shared objects/DLLs." Once again, sorry for my confusion on this point. I just have what I might consider a special case where it would be very handy to distribute a cran compiled executable.
I don't quite follow - CARN obviously distributes binaries compiled by CRAN and those are called binary packages. Can you be more specific as of what you are asking about? The two paragraphs you are quoting are about entirely different things - the first states that you can't include binaries in *source* packages and the second describes how you can build executables beside dynamic objects in packages so that CRAN can include them in *binary* packages. It doesn't cover distribution. What you refer to are rules for *source* packages which can't distribute binaries, but you can always use a binary package (which contains binaries). Note that the issue in question is not who built the binary but whether it could have been injected by 3rd party or not (hence all binaries are disallowed in source packages since there is no way to tell). Cheers, Simon
On 18/05/2012 16:11, Daniel Fuka wrote:
Sorry for this intrusion, but I am confused by two statements that appear to conflict at some level in Writing R Extensions,
You may be confused, but the documentation does not conflict. > and wanted
to make sure I understand the answer to: Can we distribute a portable executable compiled from source by CRAN in CRAN?
Yes. Take a look at e.g. package Rserve (and there are others which do this via src/Makefile.win).
The following section of Writing R Extensions appears to not be addressing this issue, as in this case we are discussing portable CRAN compiled binaries, and not binaries that are submitted to CRAN:
Note that by definition a binary is not portable: it is tied to one OS and perhaps one architecture on that OS. The following is about source packages.
"A source package if possible should not contain binary executable files: they are not portable, and a security risk if they are of the appropriate architecture. R CMD check will warn about them unless they are listed (one filepath per line) in a file BinaryFiles at the top level of the package. Note that CRAN will no longer accept submissions containing binary files even if they are listed." The following section seems to indicate special cases in which packages can create binary files: "In very special cases packages may create binary files other than the shared objects/DLLs in the src directory. Such files will not be installed in multi-arch setting since R CMD INSTALL --libs-only is used to merge multiple architectures and it only copies shared objects/DLLs. If a package wants to install other binaries (for example executable programs), it should to provide an R script src/install.libs.R which will be run as part of the installation in the src build directory instead of copying the shared objects/DLLs." Once again, sorry for my confusion on this point. I just have what I might consider a special case where it would be very handy to distribute a cran compiled executable.
You need to discuss that with CRAN, not here.
Thanks! Daniel Fuka
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
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
Thanks Simon,
In this case, I am talking specifically about allowing CRAN to compile
source into an executable to be distributed, as discussed in the
second paragraphs "very special cases .. for example executable
programs". So, when someone runs install.packages("mypackage"), they
get a package that contains an executable that can be run from outside
of R.
Can I submit a package to CRAN that will compile source into an executable?
I hope this clears the mud on my first post.
Thanks!
dan
On Fri, May 18, 2012 at 11:24 AM, Simon Urbanek
<simon.urbanek at r-project.org> wrote:
On May 18, 2012, at 11:11 AM, Daniel Fuka wrote:
Sorry for this intrusion, but I am confused by two statements that appear to conflict at some level in Writing R Extensions, and wanted to make sure I understand the answer to: Can we distribute a portable executable compiled from source by CRAN in CRAN? The following section of Writing R Extensions appears to not be addressing this issue, as in this case we are discussing portable CRAN compiled binaries, and not binaries that are submitted to CRAN: "A source package if possible should not contain binary executable files: they are not portable, and a security risk if they are of the appropriate architecture. R CMD check will warn about them unless they are listed (one filepath per line) in a file BinaryFiles at the top level of the package. Note that CRAN will no longer accept submissions containing binary files even if they are listed." The following section seems to indicate special cases in which packages can create binary files: "In very special cases packages may create binary files other than the shared objects/DLLs in the src directory. Such files will not be installed in multi-arch setting since R CMD INSTALL --libs-only is used to merge multiple architectures and it only copies shared objects/DLLs. If a package wants to install other binaries (for example executable programs), it should to provide an R script src/install.libs.R which will be run as part of the installation in the src build directory instead of copying the shared objects/DLLs." Once again, sorry for my confusion on this point. I just have what I might consider a special case where it would be very handy to distribute a cran compiled executable.
I don't quite follow - CARN obviously distributes binaries compiled by CRAN and those are called binary packages. Can you be more specific as of what you are asking about? ?The two paragraphs you are quoting are about entirely different things - the first states that you can't include binaries in *source* packages and the second describes how you can build executables beside dynamic objects in packages so that CRAN can include them in *binary* packages. It doesn't cover distribution. What you refer to are rules for *source* packages which can't distribute binaries, but you can always use a binary package (which contains binaries). Note that the issue in question is not who built the binary but whether it could have been injected by 3rd party or not (hence all binaries are disallowed in source packages since there is no way to tell). Cheers, Simon
On May 18, 2012, at 11:32 AM, Daniel Fuka wrote:
Thanks Simon,
In this case, I am talking specifically about allowing CRAN to compile
source into an executable to be distributed, as discussed in the
second paragraphs "very special cases .. for example executable
programs". So, when someone runs install.packages("mypackage"), they
get a package that contains an executable that can be run from outside
of R.
Can I submit a package to CRAN that will compile source into an executable?
Yes - that is what the second paragraph describes (and as Brian pointed out there are examples on CRAN like Rserve). Cheers, Simon
I hope this clears the mud on my first post. Thanks! dan On Fri, May 18, 2012 at 11:24 AM, Simon Urbanek <simon.urbanek at r-project.org> wrote:
On May 18, 2012, at 11:11 AM, Daniel Fuka wrote:
Sorry for this intrusion, but I am confused by two statements that appear to conflict at some level in Writing R Extensions, and wanted to make sure I understand the answer to: Can we distribute a portable executable compiled from source by CRAN in CRAN? The following section of Writing R Extensions appears to not be addressing this issue, as in this case we are discussing portable CRAN compiled binaries, and not binaries that are submitted to CRAN: "A source package if possible should not contain binary executable files: they are not portable, and a security risk if they are of the appropriate architecture. R CMD check will warn about them unless they are listed (one filepath per line) in a file BinaryFiles at the top level of the package. Note that CRAN will no longer accept submissions containing binary files even if they are listed." The following section seems to indicate special cases in which packages can create binary files: "In very special cases packages may create binary files other than the shared objects/DLLs in the src directory. Such files will not be installed in multi-arch setting since R CMD INSTALL --libs-only is used to merge multiple architectures and it only copies shared objects/DLLs. If a package wants to install other binaries (for example executable programs), it should to provide an R script src/install.libs.R which will be run as part of the installation in the src build directory instead of copying the shared objects/DLLs." Once again, sorry for my confusion on this point. I just have what I might consider a special case where it would be very handy to distribute a cran compiled executable.
I don't quite follow - CARN obviously distributes binaries compiled by CRAN and those are called binary packages. Can you be more specific as of what you are asking about? The two paragraphs you are quoting are about entirely different things - the first states that you can't include binaries in *source* packages and the second describes how you can build executables beside dynamic objects in packages so that CRAN can include them in *binary* packages. It doesn't cover distribution. What you refer to are rules for *source* packages which can't distribute binaries, but you can always use a binary package (which contains binaries). Note that the issue in question is not who built the binary but whether it could have been injected by 3rd party or not (hence all binaries are disallowed in source packages since there is no way to tell). Cheers, Simon