Max,
This is indeed a thorny issue.
The systems I've worked with tend to grow to this size eventually but do so a few classes at a time and hence the only real trouble came when we had to migrate to newer versions of Cach�.
My experience in this area is highly empirical and people better informed may be able to rebut these points, but:
* $system.OBJ.CompileAll() will seldom resolve dependencies correctly
* This is very difficult per-se and trying to e.g. write your own dependency checker is not trivial
* What I've done in the past is simply run CompileAll() several times until the whole system is compiled, but this can take ages even with C5 (_much_ faster than C4) and a good machine
An elaboration of the last is writing code that queries all classes in a namespace, compiles them one by one and saves the result of compiling each. Subsequent runs would only compile classes that failed to compile previously, assuming those failures were due to unresolved dependencies. If you want to recompile everything just clear the compile log before running.
Every now and then I also ran into these odd circular dependencies and would simply have to compile two classes manually with a lot of switches set :) ("br" or somesuch)
In short IMHO this is not a trivial problem and I can easily see why even ISC may have a hard time with it.
HTH,
Ram�n
-- ZCacheLib - Open Source Extensions for Cach� http://www.zcachelib.org
