[M3devel] response file changes?

[Jay]

"response files" are files that contain command lines, to overcomecommand line length limits. (Why the limits are so small? Lame.)
CM3 has built in support for them.
I have seen them not be deleted reliably.
While the deletion should be made more reliable, I propose they be writteninto the target directory instead of "temp".
That is, nearly all writes should be into the target directory.This is what is reliably cleaned up when you run "realclean".
 
I realize there is a tension between putting things that belong together together, and reliable deletion, vs. load balancing of I/O. "Temp" is sometimes smaller/faster.
I had already worked around this by wrapping up the response file supportin Quake code that moves the file into the target directory immediatelyafter creating it. I'll be able to remove that code, and live with theunreliably deleted files only when using older tools.
?
Also, the built in support uses a heuristic.For shorter command lines, it doesn't use a response file.I found that surprising and a bit disappointing.While a more immediately readable log is valuable, consistency is too.
Leave it alone or make it always use a response file?
The Microsoft C compiler and linker dump the output of any response filethey are given, so that gets you a readable log.
 
I don't care all that much.
Maybe I'll just look into why the deletion is unreliable, but I figure "cleanup" is always unreliable because you might control-c the build, or the compiler might crash, etc. There is a "delete on close" flag in Windows, but I think it has a problem in that you have to keep the file open and if anyone else also opens it, they might need file_share_delete, not sure. File_share_delete not being supported on Win9x, maybe not much used?
 
 - Jay
_________________________________________________________________
Need to know the score, the latest news, or you need your Hotmail®-get your "fix".
http://www.msnmobilefix.com/Default.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080223/19446012/attachment-0002.html>