R devel - Feb 2010 - Where does install.R go when R gets compiled? Or, how to experiment with changes to install.R?

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?

pj
-- 
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas

On Thu, Feb 18, 2010 at 11:33:14AM -0600, 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.
Hmm, why not take the easy way:

    clean_dst $PROTO
    cd $TMPBUILD
    mkdir -p $PROTO/R/library
    $R_HOME/bin/R CMD INSTALL -l $PROTO/R/library $TMPBUILD

$PROTO is the directory, where the R module gets installed (e.g. /tmp/R),
$TMPBUILD is the directory with the R module sources (e.g. /tmp/build/quantreg)
and the rest is obvious.

Than you need to care about/package $PROTO/R/library, only. 

Built about 150 R packages this way 4 Solaris without any pkg problems ...

Regards,
jel.
-- 
Otto-von-Guericke University     http://www.cs.uni-magdeburg.de/
Department of Computer Science   Geb. 29 R 027, Universitaetsplatz 2
39106 Magdeburg, Germany         Tel: +49 391 67 12768

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
>