Some separate compilation errors/questions

[Jens]

I just tried separate compilation from gwt trunk on a very small project. In this project I never inherited c.g.g.user.User directly but only the most specific modules I need.

One such module is c.g.g.dom.DOM which fails with separate compilation as MediaElement needs classes from c.g.g.media.dom.client but c.g.g.dom.DOM does not inherit it. 

Should we open bugs for such problems or does separate compilation expect users to always inherit c.g.g.user.User? 

When I do so the compilation works again because it seems like it does not want to compile the DOM module directly anymore but only the User module which has c.g.g.d.DOM and (indirectly) c.g.g.media.dom.DOM inherited. I guess the different compilation behavior is because of the type="fileset" attribute on all these specific modules? 

Can anyone explain what type="fileset" exactly does? Are there other types?

I also noticed that gwteventbinder does not work with separate compilation and it seems like it is only fixable with a breaking change. Anyone who is interested in it can take a look at https://github.com/google/gwteventbinder/issues/20

-- J.

[John Stalcup]

Hey Jens

Thanks for trying it out.

I would open bugs for these issues. Separate compilation does not assume that c.g.g.user.User is inherited. (It does secretly add an implicit c.g.g.core.Core dependency, but the user doesn't need to do anything for that).

--
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 google-web-toolkit-co...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John Stalcup]

If you're depending directly on anything (in this case DOM) then that thing needs to be separately compilable. Which means it's .gwt.xml file needs to *not* be marked with type=fileset at the top.

If you look at User.gwt.xml and Core.gwt.xml you'll see that these are already not filesets, since they have been verified to be compilable on their own (meaning they accurately include their dependencies).

You can try changing DOM.gwt.xml by removing the type=fileset marker, and then deal with any compile failures that result. (Likely DOM.gwt.xml does not accurately include all its dependencies and fixing it will require adding some references and breaking some resulting circular references. This is what Goktug has been doing recently with some other modules).

John

[John Stalcup]

Going into a little bit of detail on the meaning of type=fileset:

You can think of a type=fileset module as being just a bag of source files and properties. It exists only to forward those source files and properties onward to some library module which will actually do the compilation.

The reason filesets exist right now is that the standard GWT libraries contain roughly 150 module files forming a graph with extensive circular references in the modules and in the source. Filesets allow us to bundle circularly referent areas together into a single chunk which can be compiled as a group. At the moment there are only a couple of modules (Core and User) which have been cleaned up to be compilable on their own. Over time we will break these circular references and will have more independent chunks that are independently compilable.

The existence of filesets create a danger that two different libraries depend on the same fileset, and result in having duplicate copies of the compiled source in the output. But the incremental build system will detect this situation and throw an error (pointing out the two libraries that are supplying duplicate source).

[Goktug Gokdogan]

On Tue, Apr 22, 2014 at 2:28 PM, 'John Stalcup <sta...@google.com>' via GWT Contributors <google-web-tool...@googlegroups.com> wrote:

If you're depending directly on anything (in this case DOM) then that thing needs to be separately compilable. Which means it's .gwt.xml file needs to *not* be marked with type=fileset at the top.

If you look at User.gwt.xml and Core.gwt.xml you'll see that these are already not filesets, since they have been verified to be compilable on their own (meaning they accurately include their dependencies).

You can try changing DOM.gwt.xml by removing the type=fileset marker, and then deal with any compile failures that result. (Likely DOM.gwt.xml does not accurately include all its dependencies and fixing it will require adding some references and breaking some resulting circular references. This is what Goktug has been doing recently with some other modules).

I untangled a lot of dependencies for this modules and made most them separately compilable but I'll need some time before sending out the patches.

[John Stalcup]

Also, I just want to mention that the incremental compile is behind an experimental flag because it's still very raw.

There are some low hanging fruit improvements that should make a big difference:

* Teach IncrementalBuilder to run the compiles in parallel.

* Add stricter freshness checking so that we don't have to recompile all of the modules that depend on module Foo, if the change in module Foo didn't change the interface of any of its source files.

* Stop deleting the old library directory on every launch of SuperDevMode

* Improve ModuleDef parsing so that we can do an initial freshness check on existing library files on disk, even on a fresh launch of SuperDevMode.

* more things...

I'll file some GWT issues for these and maybe get some community involvement on splitting up the work.

[Jens]

Also, I just want to mention that the incremental compile is behind an experimental flag because it's still very raw.

Thats fine, it can only get better :)

 

 

* Stop deleting the old library directory on every launch of SuperDevMode

That one already annoyed me while fixing compile errors one by one because the User module takes some time for the initial compile.

 

 

I'll file some GWT issues for these and maybe get some community involvement on splitting up the work.

Worth a try I would say. I guess there are quite some people interested in a faster SDM ;)

-- J.

[Jens]

I untangled a lot of dependencies for this modules and made most them separately compilable but I'll need some time before sending out the patches.

Ah cool, good to know. Looking forward to see the patches.

-- J.

[Jens]

Going into a little bit of detail on the meaning of type=fileset:

Thanks for the information. Seems like I had a similar idea of what it does.

Is it allowed to have a type=fileset on the root module of a GWT app? I ask this because at work we have a large single module app and we are working on extracting smaller modules from it. Sometimes we have smaller modules that still need classes from the root module, e.g. app -> feature A -> app, until we continue to extract additional smaller parts from the app.

If "app" is what we compile, is it allowed to mark "app" and "feature a" as fileset so we don't get a circular dependency error? Or do we need to introduce an additional module that inherits both "app" and "feature a" similar to what c.g.g.user.User does and then compile that new module?

-- J.

[Jens]

Thanks for trying it out.

I would open bugs for these issues.

After fixing all errors in my small app I encountered a final error I am unable to solve. The incremental compiler can't seem to find the EntryPoint of my app. After some debugging it looks like that all classes pulled in by my entry point module (root module) are missing in the corresponding LibraryTypeOracle. In case I did something strange I created a new empty project with EntryPoint and this fails to compile as well:

https://code.google.com/p/google-web-toolkit/issues/detail?id=8686

-- J.

[John Stalcup]

Incremental builds are strict about source paths.

Normal compiles implicitly include "client", but incremental builds do not because doing so would create massive amounts of duplicate source inclusion.

Based on the error message i think you need to add a "<source path="client" />" to the biz/codr/gwt/incremental/Inremental.gwt.xml file. Let me know if this fixes it for you.

[John Stalcup]

I have a patch in review at https://gwt-review.googlesource.com/#/c/7290/ to make that error message more helpful when strict source inclusion is turned on.

[Jens]

Hey Jens

Thanks for trying it out.

Hey John,

are you aware of issues regarding GWT's RuntimeRebinder classes and incremental compilation? I am trying SDM incremental from time to time and have these issues:

1.) In current GWT trunk a new app with empty entry point does not work anymore at runtime when using incremental compile. It fails with

1. Uncaught TypeError: Cannot read property 'containsKey__Ljava_lang_Object_2Z' of undefined Example-0.js:8181
1. com_google_gwt_lang_RuntimeRebinder_createInstance__Ljava_lang_Class_2Ljava_lang_Object_2Example-0.js:8181
2. java_util_AbstractHashMap_clearImpl__VExample-0.js:21715
3. java_util_AbstractHashMap_$init__VExample-0.js:21695
4. java_util_AbstractHashMap_AbstractHashMap__VExample-0.js:21667
5. java_util_HashMap_HashMap__VExample-0.js:26220
6. com_google_gwt_lang_RuntimeRebinder_$clinit__VExample-0.js:8167
7. com_google_gwt_lang_RuntimeRebinder_createInstance__Ljava_lang_Class_2Ljava_lang_Object_2Example-0.js:8178
8. com_google_gwt_core_client_impl_Impl_$clinit__VExample-0.js:3534
9. com_google_gwt_core_client_impl_Impl_registerEntry__Lcom_google_gwt_core_client_JavaScriptObject_2Example-0.js:3728
10. com_google_gwt_lang_ModuleUtils_registerEntry__Lcom_google_gwt_core_client_JavaScriptObject_2Example-0.js:197
11. (anonymous function)

2.) In an older GWT trunk version, which does not cause the issue in 1.), sometimes the RuntimeRebinder.runtimeRebindRuleByRequestTypeName Map has some missing entries. Because of that the app fails to start at runtime when using incremental compilation because no RuntimeRebindRule for my AppGinjector can be found in the map. When not using incremental compile, everything works.

-- J.

[Miroslav Genov]

Hello, 

Is there issue about this ?

I was searching for it, but I can't find it. 

[Jens]

Is there issue about this ?

I was searching for it, but I can't find it.

I haven't created one yet. I thought it's maybe just me having the issue.

-- J.