One more thing -- because bugs happen in the application, implementation or underlying system, I have found that atomicity in filesystem operations is very useful in avoiding corrupt half-compiled objects that pollute the build in ways that the user doesn't always suspect (and therefore spends countless hours chasing).
Lacking a transaction interface to the filesystem from the OS, you can cheaply achieve atomicity in the creation of object files by first non-atomically creating an object file with a temporary name (such as foo.o.tmp or foo.o.tmp-$HOSTNAME-$PID-$TIMESTAMP) and atomically rename it when it is complete (bonus if you check whether it creates any change, and abort the new file if no change was necessary - you'll play much nicer with timestamp-based dependency managers). In my experience, implementing such a technique is cheap, and leads to much more robust (and faster) incremental building of large systems. (I haven't checked, so maybe PLT already does that in which case, congratulations!) [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The program isn't debugged until the last user is dead. 2009/8/12 Dave Gurnell <d.j.gurn...@gmail.com>: >> What if you actively want to use two (or more) different versions of >> PLT? Say, one for "stable" developments, one for experimenting with >> the implementation? > > I do this a fair bit, and my code is big enough to make compilation a > practical necessity. I use the mzc && mzscheme solution. > > However, there are still some oddities. I have loads of dev links to > PLaneT packages, and those have to be recompiled too. > > Sometimes (not sure what the trigger for this is) mzc doesn't follow the > dependencies properly and I have to some bytecode nuking to get things > working. > >> If that scenario is probable/supported, then you might still >> automatically compile, but put the compiled files in directories the >> name of which identify the implementation. > > This is something I'd be very much in favour of. I think it would fix all of > the above problems. > > Cheers, > > -- Dave > > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev > _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
