From edd at debian.org  Sun Dec 19 00:35:07 2004
From: edd at debian.org (Dirk Eddelbuettel)
Date: Sun Dec 19 00:35:20 2004
Subject: [Rd] More on Lazy loading errors building its package in a chroot
In-Reply-To: <20041218191010.C819112FF3@mprdmxin.myway.com>
References: <20041218191010.C819112FF3@mprdmxin.myway.com>
Message-ID: <20041218233507.GA19963@sonny.eddelbuettel.com>

On Sat, Dec 18, 2004 at 02:10:10PM -0500, Gabor Grothendieck wrote:
> > I now have the package built in a chroot -- but at the price of setting
> > 'LazyLoad: no' in DESCRIPTION. 
> > 
> > I do not quite understand why that is needed. Can someone else help? I can
> > provide the following pointers for its-1.0.4
> > 
> 
> I have had problems on Windows in which I had to pay the
> same price and it turned out that by using forward slashes
> rather than backslashes in pathnames my R CMD ...  line I
> circumvented it.  Now this obviously is not your problem but
> it shows that such a workaround can represent unexpected
> causes.

Indeed.

> > * The file 'DESCRIPTION' has the Depends on methods, stats and Hmisc. Under 
> > Debian Hmisc and acepack get properly loaded as needed to build this.
> > 
> > * A file 'install.R' still exists from the older version. I reckon it can
> > be removed, but it doesn't seem to matter either way.
> > 
> > * The file 'NAMESPACE' is there, it contains import(), export(),
> > exportClass() and exportMetods() directives.
> > 
> > * The file R/itspkg.r has 
> > .onLoad <- function(lib, pkg) require(methods)
> > [...]
> > as.its.zoo <- function(x) {
> > stopifnot(require(its))
> > index <- attr(x, "index")
> > stopifnot(inherits(index, "POSIXct"))
> > attr(x, "index") <- NULL
> > its(unclass(x), index)
> > }
> 
> The as.its.zoo function was originally part of the 'zoo'
> package.   It was moved to 'its' since it seemed to make
> more sense there.  The 'require(its)' line was needed when it
> was part of 'zoo' but now that it is part of 'its' I think
> it can be eliminated.  Check if that has any effect.

I had commented that out earlier in the week during my first attempts at
building the package.
> 
> > and I have the feeling that these may interfere with the LazyLoad
> > directive. But I just don't understand how something can work in 
> > session with a controlling terminal, but fail in the chroot'ed batch
> > built. 
> > 
> > Comments would be highly welcome. But please speak very slowly when it comes
> > to S4 and LazyLoading matters. 
> 
> There is an article on Lazy Loading in R News you may wish
> to read.

Yes, I have planned to reread it.

Thanks for the feedback.

Dirk

-- 
If you don't go with R now, you will someday.
  -- David Kane on r-sig-finance, 30 Nov 2004


[Rd] More on Lazy loading errors building its package in a chroot
Dirk Eddelbuettel