[Rd] R CMD build/check
Paul Gilbert
pgilbert@bank-banque-canada.ca
Wed, 12 Apr 2000 14:34:40 -0400
>`\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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._