Dear All,
Thanks for the input - it was sufficient for me to figure out a
solution, which I'll briefly describe here for future reference. This
draws primarily on the section of Writing R Extensions quoted by Martin
Morgan below, giving rise to the idea of combining environmental
variables, and t
Section 1.2 of 'Writing R Extensions' says
Another example is when a package installs support files that are required at
run time, and their location is substituted into an R data structure at
installation time. The names of the top-level library directory (i.e.,
specifiable via the ‘-l’ argume
On Wed, 19 Jun 2019 at 16:47, mark padgham wrote:
>
> Yeah, but that would require completely rewriting the C code to accept a
> variable for something that is used hundreds of times as a simple macro.
> (Most of that C code is an old library bundled with the package, so not
> my work in that rega
Yeah, but that would require completely rewriting the C code to accept a
variable for something that is used hundreds of times as a simple macro.
(Most of that C code is an old library bundled with the package, so not
my work in that regard.) It would still be enormously easier to robustly
provide
What do you mean by
"call an external text file"
? Text files are data... do you want to open it and read it? Are you familiar
with the system.file() function?
On June 19, 2019 5:45:51 AM CDT, mark padgham wrote:
>Dear All,
>
>I'm developing a package which primarily relies on C code that its
Dear All,
I'm developing a package which primarily relies on C code that itself
has to call an external text file representing a dictionary or lookup
table. The location of this file is defined in a C macro, the file
itself packaged in "./inst/dict/" and so currently called as
"#define mylocation
