Paul Johnson wrote:
Hello, everybody.
I apologize if this is obvious. I've not tried to make changes in R
code within the R source itself before.
I'm pursuing an experiment to make RPM files for R packages
on-the-fly. Any time I install an R package successfully, I want to
wrap up those files in an RPM. Basically, the idea is to "hack" an
option similar to --build for R CMD INSTALL.
I observe in the R source code this is the file that handles installs
src/library/tools/R/install.R
The R DESCRIPTION file has the information required and the code in
install.R is quite clear and easy to understand. I *think* I see what
I need to do.
But I don't understand how to test the effect of my changes without
re-compiling R and re-installing it.
In the installed R, there is no file "install.R", so there's no
obvious place to hack on it.
Is it actually necessary to recompile & re-install R every time I want
to test changes to that file?
The source to most packages is parsed and saved in binary images which
are loaded as necessary by R. So install.R has been parsed and included
in library/tools/R/tools.rdb.
Debugging system functions can be a little tedious. In some cases you
can create new copies of the functions in your workspace; set their
environment to the environment of the original function, and they'll
work properly. The main difficulty is that other functions in the
package won't see your version, they'll see the original (as will your
own, if it calls itself recursively.)
You can replace the original function in the package namespace using
assign(), but you need to handle unlocking and locking of bindings.
Normally I'd recommend just editing the source and running make to
incorporate the changes; it's too easy to miss a step if you try to take
shortcuts, and then you need to debug your edits, not just your code.
Duncan Murdoch
pj
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
