Hey John,
> it means having an optional compilation path that does not recompile
> the entire world (as the current monolithic compile path does) and
> instead tries to recompile just files (or or modules) that have
> changed.
Spiffy! Out of curiosity, would the API look something like:
theBackendCompile.recompile(List<File> filesThatChanged)
Such that the existing ResourceOracle/TypeOracle instances are mutated
with the updated state, instead of being rebuilt?
AFAIK, historically most of the optimizations around "incremental"
compiles have always required going back to building ResourceOracle,
TypeOracle from scratch, but speeding it up with caching.
...IIRC. It's been a little while since I've poked at the code.
I know I'm being a broken record, but I think the mutative/truly
incremental approach, while a (large) PITA to build, in the long run is
the only solution that would be fast enough to get SuperDevMode fast
enough such that it's "hit save in Eclipse, the js file is updated,
done!", just like Java (and web) developers are used to.
(I know Brian really doesn't like solutions that require Eclipse, but I
think the same mutative/incremental compiler API could just as well be
called by an Eclipse plugin or an IDEA plugin or even a Java daemon
polling the file system for changes. It's not IDE-specific.)
Feel free to ignore my musings given I'm not actually contributing
anything to the effort; just curious as to how things are going.
- Stephen
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups "GWT
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
