Max,
I am late to this thread buy I may have something that helps.
We faced a problem like this a while ago, similar, our structure grew large
with lots of dependencies, and some circular references and very similar
symptoms as you in general.
We seem to have solved in now.
We compile using the command
d $System.OBJ.CompileAll("f")
It took a lot of effort to narrow down the problem.
One of the most annoying to find was using 'Select *' in queries. Apart
from it being bad form anyway, it seems to cause problems in the compile,
and doesn't report a proper error.
Apart from that we just went looking for all our errors and removed a lot of
old 'unused/unneeded' classes and dependencies.
It was an incremental process finding one error fixing it then compiling all
again then finding the next error and repeating until the compile was clean.
We still have one error reporting at the end, unassociated to the class that
has the problem, but it does not seen to be causing a problem (that we can
find).
I recommend turning logging on when doing the compile in Terminal so that
you can go back and look over the compile output and see what the errors
are.
Once there is an error even small that class does not compile properly then
anything that is dependant on it will not compile, expanding exponentially.
We now as part of our process run a full compile after all new development
to ensure that no unexpected compile errors have been introduced. It is
easier to fix them as they are produced rather than going back later and
finding them all.
I hope this helps, and good luck, it is a frustrating problem.
Jack Stevenson
Senior Product Development Manager
Mtivity
London UK
+44 (0) 207 801 6211
"Max Sebastiani" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hello again!
>
> >
> > I would suggest you use the following format for $system.OBJ.Compile:
> >
> > Do $system.OBJ.Compile( class, "bruy" )
> >
>
> ,,we have been using "r-bkvu" until now, and also tried a lot of
> combinations, no results.
>
> > From the documentation (Do $system.OBJ.ShowFlags()), "b" will compile
> > subclasses; "r" compiles all classes that are dependency predecessors;
> > "u" avoids compiling up-to-date classes (albeit as you say sometimes you
> > need "f", the opposite); and "y" finds dependencies within SQL (and I
> > don't remember seeing that one before!)
> >
>
> The "y" is something new, I really need it! Our problems are 99% with SQL.
> Although I just tried, no visible changes to the results (with 5.07). :-(
>
> I'm thinking about moving all our queries apart, into different classes
> which somehow will be compiled later. But it's a disaster, we have about
150
> of them...
> Also, having good tests is difficult, we always have to start with an
empty
> database, or the tests will be influenced by what we have compiled before.
>
> I understand that it's a complicated issue to solve for ISC, but a
compiler
> which doesn't know how to compile its classes is a big limitation for OO
> enterprise projects. We need to scale to about 1000 classes by the end of
> the year, and now I'm seriously starting to worry about it.
>
> Max
>
>
