From berwin at maths.uwa.edu.au  Fri Dec  3 16:23:09 2010
From: berwin at maths.uwa.edu.au (Berwin A Turlach)
Date: Fri, 3 Dec 2010 23:23:09 +0800
Subject: [Rd] Clean up after "R CMD INSTALL" and/or "R  CMD check"
In-Reply-To: <alpine.LFD.2.00.1012031228310.7301@toucan.stats.ox.ac.uk>
References: <20101203195942.04e2945a@bossiaea>
	<alpine.LFD.2.00.1012031228310.7301@toucan.stats.ox.ac.uk>
Message-ID: <20101203232309.7f266be8@absentia>

G'day Brian,

On Fri, 3 Dec 2010 13:14:44 +0000 (GMT)
Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:

> > I noticed the following (new) behaviour of R 2.12.0, running on
> > Kubuntu 10.10, when installed with sub-architectures:
> 
> Yes, there are new features when there are multiple sub-architectures.

Indeed.  One new feature seems to be that if the installation of a
package via
	R arch=XXX CMD INSTALL --libs-only
fails then the package is not completely removed but rather the
previously install version is re-installed.  IIRC, I had requested this
behaviour some years ago and it is nice to see it now implemented. :)
 
> > These directories are not deleted at the end of a successful
> > INSTALL/check and I wonder if there is any particular reason for
> > this?
> 
> Because it might be partially successful and you want to look at the 
> generated objects?  

I agree that it would be helpful to look at the generated objects if
the INSTALL/check is only partially successful, that's why I asked
about a successful INSTALL/check.  However, it looks...

> In particular 'success' means that the primary sub-architecture is
> installed: others might fail.

... as if we have different definitions of what constitutes 'success';
I take 'success' as meaning successful installation for all
architectures, but accept that you are using the official definition. :)

> > Would it be possible to delete these sub-directories during clean-up
> > at the end of a successful INSTALL/check?
> 
> Try INSTALL --clean, etc.  

This does not seem to help, the directories in question are not removed.

> But I normally do this from a tarball to keep the sources clean and
> to test the reference sources.

I used to do this too but changed my habits when it was once pointed out
to me that the section "Checking and building packages" in the "Writing
R Extensions" manual starts with:

	Before using these tools, please check that your package can be
	installed and loaded.  @code{R CMD check} will @emph{inter
	alia} do this, but you may get more detailed error messages
	doing the checks directly.
 
IIRC, the context was that it took me some time to track down a problem
via "R CMD check foo.tar.gz" as the error messages were not as helpful
in locating the problem as the error messages of "R CMD INSTALL" would
have been.  But if "R CMD INSTALL" is to be run before "R CMD check"
and/or "R CMD build" it has to be run on the source directory, hasn't
it?  This looks like a chicken-and-egg problem. :)

Or are you now saying that it is o.k. to first run "R CMD build" and
then "R CMD INSTALL" on the tarball?

> There are a few improvements to R-patched in the detection of 
> sub-architectures, so you might like to see if you prefer what it 
> does.

I tried with:
   R version 2.13.0 Under development (unstable) (2010-12-02 r53747)
and
   R version 2.12.0 Patched (2010-12-02 r53747)
and I did not see any different behaviour.  The subdirectories src-32/
and src-64/ are created and not deleted.

Thank you very much for your comments/insights. 

Cheers,

	Berwin



[Rd] Clean up after "R CMD INSTALL" and/or "R CMD check"
Berwin A Turlach