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.urba...@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
>>
>>
>
>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
