[R] Re: Windows versus Unix packages in CRAN ...

[Richard A. O'Keefe]

Concerning the Rmetrics packages,

(1) There is a _much_ better thing to do than
	>simply ... to remove the stuff related to MS Win from zzz.R;
	> in partricular the lines after if( .... ) to clear your message.
	> As you can see, the info relates to the WinMenu under MS Win.
    as Janusz Kawczak suggests, and that is to *wrap* the troublesome code
    in
	if (exists("winMenuAdd")) {
	    ... original code goes here ...
	}
    The resulting code should then work *both* in Windows *and* in Unix.

    The documentation in the FAQ *does* provide quite a clear indication
    that this is something to watch out for; I found it fairly easy to
    find and work around this bit.

(2) By manually editing the 'Built:' line in the 'evir' package,
    which is a "binary" package that contains no object files,
    I was able to get a clear install of 'evir' for which all the
    examples I tried seemed to work (defined as "didn't crash" and
    "vaguely plausible output").

    The documentation doesn't mention this anywhere; it was a crazy thing
    to try, but noticing that the package didn't contain any .obj .dll
    .lib .o .a .so &c files suggested to me that it might work.

(3) Getting the sources of the fBasics package and putting the
    if (exists("winMenuAdd")) {} wrapper in zzz.R was not sufficient to
    make fBasics "work" under Solaris:  one of the Fortran codes exercised
    by example(distributionFits) crashes (UNIX signal).  My understanding
    is that it also does this under Linux.
	
    At this point my knowledge and skills ran out.  I'm a fairly fluent
    "speaker" of Fortran, but know nothing about *debugging* a mixture of
    R, R internals, and Fortran.  The fact that it was an addressing fault
    which showed up in Unix but not Windows makes me suspect a data alignment
    problem, possibly triggered by a data length error, but it's going to
    need someone else to fix it.