Thanks for th input. I think that I will give the wrapper bit a try.
--jason
On 29-Jul-98 Nelson Minar wrote:
> To all you bozos sending me mail saying "get me off this list", I have
> nothing to do with subscribership. Try talking to
> [EMAIL PROTECTED] or [EMAIL PROTECTED]
>
>>That sounds like the problem... and yes... running rmic in /tmp runs
>>a trillion times faster.
>
> Ah, good. I'd still be curious to know why Linux is so much worse than
> Solaris with unbuffered NFS writes. Again, my guess is that Solaris is
> caching the data a bit in the kernel before doing NFS. I believe this
> is officially disallowed (NFS writes are synchronous), but it sure
> makes things nicer. Maybe 2.1.x kernels do a better job of this?
>
>>Unfortunately I can not perform all of my compiles in /tmp. Any ideas
>>on how to get around this?
>
> This problem convinced me to switch to CVS. I do my development on
> local disk, then check the sources in to CVS on my NFS mounted (and
> backed up) disk. Not exactly a simple solution, but it was good to use
> CVS anyway.
>
> The other option is to write a shell script wrapper around rmic that
> writes to /tmp and then copies the output back.. If rmic has a -d option
> similar to javac, then it's easy. Just do something like
> rmic -d /tmp Foo.java
> mv /tmp/RMIFoo.class .
> (sorry, I don't know rmic that well. I hope the idea is clear).
> Without a -d option you'll have to copy Foo.java to /tmp first.
>
> The only other thing I could think is to reverse engineer rmic, fix it
> so that it uses a buffered output stream, and recompile it. That's
> probably illegal.
>
> (Bummer about not having source to rmic. Jini is going to be open
> source, which is incredibly cool.)
