[Rd] R CMD build/check

[Paul Gilbert]

 >`\alias{TOPIC}'
 >    The `\alias' entries specify all "topics" the file documents.

Ok. I thought TOPIC had to be an object. (In fact, I thought I was
getting another error message if it wasn't, but I must have been
mistaken as it works fine now.)

>> 2/ Specific methods get reported as undocumented functions unless the

>> generic documentation has an alias line for the specific method. This

>> is not a problem when everything is in one package, however, for many

>> of my specific methods the generic method is in another of my
packages
>> or in the base. (This can generate a lot of warning, which obscure
>> more important warnings.) I'm putting a "stub" description in to
>> eliminate all the warnings, but I'm not sure if this is the ideal way

>> to do this.

>Not sure if I understand this correctly.  If you have a specific method

>say foo.dse then you'd have
> \alias{foo.dse}
>etc.  So why would this be undocumented?

It is not a problem if everything is in one package. But when that is
not the case things are a bit more complicated. For example, I have a
method print.TSdata and the documention for "print" is in base so
instead of just putting an \alias{print.TSdata} in with the
documentation for print, I need to make a little "stub"  .Rd with
\name{print.something} and put all my \alias{print.*'s in that. The same
applies to print.summary and other generic methods in the base.

In addition to the base, I have a lot of generic methods defined in my
tframe package. DSE defines specific methods for these, so the same
problem occurs. I guess in this case I could put the alias for the
specific methods in with the tframe package, but I like to think of
tframe as self-contained and expect not to need to update it as
frequently as I might add new things to DSE.

I've now gone from about 600 undocument function on my first R CMD build
down to about 100. Most of the 500 fixed have just been additional
aliases, and probably 3/4 of them had to be put in these "stub" files
because the generic method was not in the same package. (But it is worth
the trouble, I now have a much better idea where the documentation
truely is weak.)

>> 4/ R CMD build does not work for bundles, but it can be used to test
>> sub-packages and then the bundle rolled up afterwards directly with
>> tar and gzip. (This is not difficult and not a problem, but people
>> should be aware of it.)

>I should add something on this too.  Perhaps, Paul, once you release
dse
>as a package bundle I can try to make R CMD build work for bundles,
too.

ok, but I wouldn't treat it as any sort of priority. Testing the
individual packages and then rolling up the bundle seems to work pretty
well.

Paul Gilbert


-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._