[Rd] Distributing Executables.

[Simon Urbanek]

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