Oh, a concrete reason occurred to me this morning why we'd rather have the logic in Precompile.run() that binds using OptionCompilationStateRetained with OptionMaxPermsPerCompile: You'd actually like to turn off OptionCompilationStateRetained on the final pass, I mean, the last set of precompilations to run. Probably as simple as:
// Preserve module state unless this is the last iteration. options.setCompilationStateRetained(<this is the last iteration>); On Wed, Apr 8, 2009 at 9:41 PM, Scott Blum <sco...@google.com> wrote: > Yeah, we definitely need to solve this. But it does seem a little weird to > have OptionMaxPermsPerCompile extend OptionCompilationStateRetained, since > the compilation state retained stuff is kind of an implementation detail. > Somehow it seems preferable to me to handle this association in > Precompile.run(), maybe in an else statement around line 537? Can't put my > finger on why exactly. Maybe because so far the options tend to be > independent and resolutions tend to happen in the entry point classes. > Especially in this case where it wouldn't affect the processing of > arguments in any way. > > On Wed, Apr 8, 2009 at 11:00 AM, Lex Spoon <sp...@google.com> wrote: > >> Scott, when you get back, can you review this tiny patch, or propose a >> different way to solve the problem? >> >> The problem is that when precompiles are sharded, it's not actually >> sound to discard all early compilation state in the middle of >> precompile(). If this is done, then the next precompile shard will >> not have that state available. As a result, sharded precompiles are >> currently broken in trunk. >> >> What the patch does is simply turn on the option to retain compilation >> state whenever sharded precompiles are enabled. That fixes sharded >> precompiles, and is surely safe in general. >> >> Lex >> > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
