From @purd|e@@ @end|ng |rom gm@||@com  Tue Mar  5 21:41:10 2019
From: @purd|e@@ @end|ng |rom gm@||@com (Abs Spurdle)
Date: Wed, 6 Mar 2019 09:41:10 +1300
Subject: [Rd] 
 Should CRAN accept packages with non-R code that transcompiles
 into R code?
In-Reply-To: <CAD4oTHFhp1qUfFhLeCh_jBXBYH30mDjvFSeGhW5OBbnkC1t13g@mail.gmail.com>
References: <CAB8pepx3d3faRfPTDo97ebOKA1f4v=GO6_dbL7QC2DtkqZV0=w@mail.gmail.com>
 <CAD4oTHFhp1qUfFhLeCh_jBXBYH30mDjvFSeGhW5OBbnkC1t13g@mail.gmail.com>
Message-ID: <CAB8pepzNadqgsHP-tbhAaBj5RNK12hFQHChQiRG=36me6G-Ybg@mail.gmail.com>

On Tue, Mar 5, 2019 at 12:52 PM Gabriel Becker <gabembecker at gmail.com>
wrote:

> I have thought about and have (somewhere "up near the top" of my todo
> list) prototyping a preprocessor for R, and I have relevant code that emits
> (transpiles, in a way) structured comments into S4 code in
> https://github.com/gmbecker/S4Coffee.
>
> All that said, until/unless the preprocessor is officially part of the R
> CMD build step, what putting code like that on CRAN would look like is you
> keep the raw code in /inst somewhere, and you do the emitting of R code
> into R/ before building the tarball for submitting. And if you do that CRAN
> will hav eno problem accepting such a package provided it isn't disallowed
> in some other way.
>

I think that I would prefer to generate (and run) the R code during
.onLoad(), rather than pre-generate it and put it in the R subdirectory.
If it's in the R subdirectory, then we have two copies of the same thing,
plus it would need to be documented using the rd format, which I would like
to minimize, in favor other documentation formats.
Which is where CRAN may not like it...

In regards to S4Coffee, it sounds promising.
I hope you get in finished in the near future.
And I will take a closer look at it.

	[[alternative HTML version deleted]]



[Rd] Should CRAN accept packages with non-R code that transcompiles into R code?
Abs Spurdle