[M3devel] response file changes?

[Jay]

Nobody should depend on this strange heuristic-based behavior..
I know that doesn't make it so, but it does possibly legitimize changing it.
 
  > as long as their names are unique.
 
Right, like how I'm doing now _m3responsefile0.txt, _m3responsefile1.txt.
I wrap around from 9 to 0 because Quake can't do math.
In practise there's only ever one or two response files per directory, one to make in import .lib and one make a .dll, or just one to link an .exe.
C compilation doesn't use response files, but it could if the parameters got long and esp. if there were lots of C files in one directory and batch compile them instead of one at a time.. That's a nice optimization in C-based systems, not a big deal in Modula-3 with so few .c files.
 
Maybe soon I'll rip out my code, and then fix the reliable deletion, and THEN move the directory...
 
 
 - Jay



> Date: Sat, 23 Feb 2008 12:04:46 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] response file changes?> > Two short comments:> > o Response files in the target directory should be OK, as long as> their names are unique.> > o The heuristic is built-in to arglist(pfx, array), IIRC; I wouldn't> change that without need. You never know what depends on it, as it> has been there for a long time.> > Olaf> > Quoting Jay <jayk123 at hotmail.com>:> > > "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> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> 
_________________________________________________________________
Climb to the top of the charts! Play the word scramble challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080223/792f98af/attachment-0002.html>